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 is happening daily (see Stephanie Ockerman's article on planning in Scrum https://www.scrum.org/resources/blog/scrum-myths-there-no-planning-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 have been your experiences?
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 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 by experience.