Common Misconceptions and negative implications
Most leadership and product owners feel that Developers has to commit to a scope during the Sprint Planning. That is, most leadership try to implement the concept of “baseline scope” for the Sprint.
- By doing this, it prevents opportunities for inspection and adaptation during the sprint.
- Team gets “locked” into delivering baselined scope instead of trying to find out if they are going in the right direction or wrong.
- Critical opportunity to inspect and adapt is then lost and deviation is detected during the Sprint Review.
- Then starts the discussions on “change requests”, “sign offs”, “not being able to give scope properly”When the Developers yields to pressure of delivering baselined scope, the team comes under pressure and naturally working hours increase. More dissatisfaction results.
Recommendations
- At the time of Sprint Planning meeting make only a forecast instead of commitment. One should have an openness to change if the need be instead of making the team commit.
- Adapting quickly helps one get more closer to what is required to be done really.
- Once an attitude develops with the team that “we are adaptable” and “not everything needs to be done as per forecast” teams become more receptive to the change.
- Sprint Backlog always evolves – and let it evolve. The whole point why we are doing Scrum is because of the “unknown” nature of the work.
- The reason the teams are reluctant to accept changes in the Sprint Backlog is because they are asked to work late and deliver the commitment and at the same time accept all last-minute changes. One must remember that there is always a cost of the change. However, the cost of the change is taken in terms of a Scope compromise in Scrum. That means if the Sprint backlog changes, something in the Sprint Backlog may have to be pushed to the next sprint or later.
- One must remember that while the Sprint Backlog evolves, does not mean we are random and chaotic in our way of work. We are handling changes. We are not in Chaos. That means, if the changes are big, and big changes are happening frequently then it is time to either look at how we are gathering our requirements or if the Sprint Lengths are to be shortened.
This article is re-published on WORLD OF AGILE website – https://worldofagile.com/blog/myth-about-sprint-backlog-being-a-commitment/