Myth
This is kind of trick statement.
It is something which happens a lot in Scrum settings, it is quite common.
Before 2011, this statement was answered TRUE! Since 2011, the Scrum Guide replaced the word “commitment” with “forecast”.
So any Scrum organization not keeping an up-to-date Scrum guide at hand, would still believe this is not a myth!
But since 2011, the Development Team commits to the Sprint Goal, not the work!
The work, in other words the Product Backlog Items needed to achieve the Sprint Goal, are the team’s forecast. It is what they expect and predict what is needed for the goal.
The change from commitment to forecast when it comes to work is a very important one. In the first place, the organization around the Development Team could see commitment as a “set in stone” promis, which could later be used a whip to snap the team into overtime when they did not deliver it all.
It also removed empiricism from the process, since there was no room for learning from the experience and improvement. And this is vital to Scrum. Since we want the understanding of the work to evolve over time, and since we encourage new insight to emerge while working, we should have room for this emerging work to become transparent, to exist.
We know and encourage for the Sprint backlog to change. We want to have as short as possible feedback loops, so we can deliver most value, even along the way when we work and learn.
In true Scrum environments, there is a constant collaboration between the Product Owner and the Development Team, which can and will result in a constant scope change of the Sprint Backlog, while staying true to the Sprint Goal!
Right now, you should be able to see that a proper Sprint Goal is vital to Scrum, since no longer the actual (Product Backlog Items) work is committed but the Sprint Goal is.
There are a lot of cases known where organizations simply interchanged this by having a Sprint Goal saying “Get all Product Backlog Items in the Sprint Done”, which is equal to committing to the work.
Sometimes this is even because the organization might believe that when there is no commitment on the work, the Development Team would be slacking and relaxing, not producing anything valuable.
It is only when the Product Owner, Development team and organization can be coached to see the benefits of the commitment and promise of a Goal, and not necessarily on the way to get there, that true flexibility, agility, inspect & adapt and empiricism can grow.
So be glad that Scrums own empiricism and feedback loop has made sure the above statement is a myth!
Recent Comments