I once worked with a Scrum team that deliberately underestimated the size of Product Backlog items during refinement to enable them to pull oversized items into the Sprint, bypassing the team agreement that restricted larger items from being pulled into the Sprint.
Why would they do this?
The team believed that breaking down these larger tasks took time and hindered their ability to start the work immediately. Consequently, they opted for the expedient route of underestimating, allowing them to pull sizable tasks into the Sprint without further breakdown. These items often took two or even three Sprints to complete, and Developers knew in advance that this would be the case but hid this fact by underestimating the work.
This practice had severe consequences for the team's agility, predictability, visibility, adaptability, risk management, and value delivery. Let's delve into why deliberate carryover, stemming from the habit of underestimation, is a dangerous precedent that compromises the very essence of Scrum.
Agility
Agility, defined as the ability to move quickly and adapt rapidly, is foundational to Scrum. The entire purpose of Scrum is to deliver a done increment every Sprint because it enables the Scrum team to learn and adapt more quickly and enables organizational agility. However, when teams deliberately pull oversized work into the Sprint, they compromise their agility by delaying their ability to understand the true impact of their work on customer outcomes. The iterative feedback loop is disrupted, hindering the essence of Agile development.
Reduces Predictability
When Scrum teams work together, they develop a cadence of value delivery. Scrum teams learn how many Product Backlog items they typically deliver within the Sprint or how many points they typically deliver within a Sprint. This information can create accurate forecasts of future delivery and enable the Product Owner to plan for future value delivery more accurately than waterfall teams.
However, when teams cannot complete Product Backlog items within a single Sprint, this creates a high amount of variability in the work that a Scrum team typically completes. This variability comes from the fact that in some Sprints, the Scrum team delivers a lot of work (because they are finishing up large items that have taken several sprints to complete). In other Sprints, the Scrum team delivers very little work (because so much of their work cannot be completed within the Sprint). This variability makes it very difficult to accurately predict when the Scrum team will meet target delivery dates or when the Scrum team will deliver the desired value. This reduces transparency and trust.
Scrum teams thrive on developing a predictable cadence of value delivery. Deliberate carryover disrupts this predictability, introducing variability into the team's output.
Reduces Visibility
When the Scrum team delivers a usable increment of valuable product each Sprint, this creates a high amount of visibility into the progress of the Scrum team. The Scrum team doesn't 'disappear into a dark room' for months. Instead, every Sprint, the Scrum team meets with stakeholders to show what was done and to collaborate on what to do next.
In addition, by delivering value frequently and releasing it to the customer, the Scrum team also gains visibility into the impact of Product Backlog items on customer outcomes, which enables the Scrum team to learn what type of work is most valuable to the customer.
When the Scrum team has a high amount of work that cannot be completed within the Sprint, this reduces visibility for stakeholders. In addition, the Scrum team experiences delayed learning about what work is most valuable to the customer.
Scrum encourages visibility into the team's progress by delivering a usable increment every Sprint. However, when work cannot be completed within the Sprint, stakeholders have reduced visibility into significant portions of the team's work, and the Scrum team lacks information on the impact of their work on customer outcomes. This lack of transparency diminishes the effectiveness of collaborative efforts between the team and stakeholders.
Ability to Change Direction
When there is a high amount of work that cannot be completed within the Sprint, this creates sunk costs that make it difficult for the Product Owner to change direction. The fear of losing value invested in partially completed tasks hinders the product owner's ability to adapt to new information and adjust the product's direction.
Increases Risk:
Incomplete work introduces various risks, including uncertainty about the anticipated value of Product Backlog items once they are released. Technical risks are exacerbated as delays in delivering increments hinder the team's ability to validate whether chosen technical solutions are feasible.
Delays Value Delivery:
In Scrum, the goal is to deliver a potentially releasable increment every Sprint. Improperly sized Product Backlog items disrupt this rhythm, extending the time to deliver a Product Backlog item. This delay compromises the Product Owner's ability to make timely decisions regarding when to release the product to customers.
Conclusion
The cautionary tale of the Scrum team that opted for deliberate underestimation is a stark reminder of the pitfalls associated with carryover. Teams must recognize and address the adverse effects of this practice to ensure the success of their Scrum endeavors and contribute to the organization's overall efficiency.
To learn more about the ‘why’ behind the Scrum framework - and to have fun at the same time - sign up for Rebel Scrum’s Professional Scrum Master course.
Make this the year you collaborate with your peers to improve your adoption of Agile frameworks like Scrum and Kanban. Get tickets today for discounted pricing at the Scrum conference that will leave you buzzing with ideas from fellow practitioners and industry experts
Comments