DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Scrum Myth: There is Failure in Not Finishing All Sprint Backlog Items

Scrum Myth: There is Failure in Not Finishing All Sprint Backlog Items

The success of a Sprint is based more on your teams ability to adapt to, and overcome, challenges, than its ability to hit a number.

Todd Miller user avatar by
Todd Miller
·
Feb. 22, 17 · Opinion
Like (4)
Save
Tweet
Share
3.80K Views

Join the DZone community and get the full member experience.

Join For Free

A Scrum myth that I have encountered is when not finishing all Sprint Backlog Items in a Sprint is perceived as a failure. I have seen organizations go as far as implementing performance indicators around Sprint Backlog completion percentage (yikes!). A recent conversation I had with a developer reminded me how costly this myth can be.

An Example

A weary developer had worked hard with his team to solve some really tough problems. A new, unfamiliar technology was being implemented and during Sprint Planning the Development Team was optimistic it could easily be introduced into the product. Despite a valiant effort, the Development Team completed about half of what they forecasted.

"This Sprint was an epic failure, we barely got fifty-percent of our Sprint Backlog finished," the developer said. When I asked if the team had met their Sprint goal he replied, "well, we got the new technology implemented and deployed into the test environment but we didn't get anywhere near as much done as what we thought we might.”

The Product Owner had been aware of the issues the Development Team was having with the new technology.  They worked with the team to identify what Sprint Backlog Items were the worthiest of being completed. They negotiated what might be a first acceptable take at the implementation of the new technology as the Sprint wore on.

Despite this healthy and expected dialog, there was a looming perception that the Development Team had failed. It’s important to note that in this example the perception of failure was coming from the Scrum Team itself not from outside influencers (stakeholders or management).

A Sprint Backlog Emerges

Expecting a Development Team to have a perfect plan at the onset of a Sprint is in direct conflict with empiricism. In Scrum, we are guided by experience where planning and re-planning happen daily (see Stephanie Ockerman's article on planning in Scrum).

During Sprint Planning, a Development Team will forecast and select work in cohesion with the Product Owner’s wishes for the Sprint. The forecast is based on that day’s "weather."  That plan, known as the Sprint Backlog, emerges in the same way the Product Backlog does as new information is discovered. A higher-level objective for the Sprint, called a Sprint goal, is a scope negotiating point for the Development Team and the Product Owner. When the Sprint goal is threatened by unforeseen work, the Development Team raises the issues to the Product Owner and they work together to find a resolution.

The Development Team in the example was optimistic and aggressively going after the implementation of the new technology. However, their initial plan didn’t turn out the way they had expected. They negotiated during the Sprint with the Product Owner and kept their Sprint goal intact. The Increment produced at the end of the Sprint included a “done” implementation of the new technology, albeit it didn’t contain everything initially forecasted.

Significant in the example is that the perception of failure came from the Development Team which might be more easily remedied than if it came from outside influencers. Why were there feelings of failure? The embattled Scrum Team can use this as a topic of discussion in the Sprint Retrospective, the event in Scrum where the Scrum Team meets and discusses improvements that can be made in the next Sprint.

Let’s imagine that stakeholders or management showed disappointment in the team not finishing one-hundred percent of the Sprint Backlog Items. Often used in Scrum is a metric called velocity, this is the measure of how much work a Development Team completes in a Sprint.

Consider the following:

  • What if those outside influencers used a metric such as velocity as a performance indicator?
  • What if there was an external expectation for a Development Team to keep up a particular velocity or finish one-hundred percent of every Sprint Backlog?
  • How might morale be impacted?
  • How might this affect the Development Team’s comfort in being transparent?

Often times the answers to these questions are met with extremely negative consequences. What has been your experience?

Conclusion

Success in a Sprint is not defined by whether all of the forecasted Sprint Backlog Items were completed. Rather, success is defined by the Increment that was produced and how a Scrum Team inspects and adapts based on the feedback of that Increment. In a field such as software development, which is heavily dependent on the knowledge and skills of the Development Team, finding a path to “done” often happens in real-time as the work is being executed. Allow the Sprint Backlog to emerge and leverage the Scrum framework to guide you through experience.

Sprint (software development) scrum

Published at DZone with permission of Todd Miller. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Core Machine Learning Metrics
  • Continuous Development: Building the Thing Right, to Build the Right Thing
  • Best Practices for Writing Clean and Maintainable Code
  • The 31 Flavors of Data Lineage and Why Vanilla Doesn’t Cut It

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: