The Scrum Team plans their work in the Sprint Planning meeting and that planned scope (Product Backlog Items) is meant to be respected… it is a commitment by the team. In exchange for that commitment, the rest of the organization commits to leaving the team alone to focus on its work. Focus and commitment are both important values of Scrum. Any interruption to any individual Team Member except the ScrumMaster and Product Owner is considered a cause for relieving the Team of its commitment. This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work. If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its commitments and this will diminish trust between the team and its stakeholders. That lack of trust will lead to onerous control mechanisms that reduce the team’s ability to self-organize which, in turn, will prevent the team from becoming a high-performance team.
Affiliated Promotions:
Please share!
Thank-you Mishkin for sharing!
I have heard the scope of work for a Sprint addressed from this angle a few times now, but I have stumbled upon another aspect of this part of Scrum – the team becoming good at defining the scope of a Sprint, and actually delivering on the commitment. I wonder whether you have a rule, yet, where you write about that.
The power of succeeding in meeting the defined goals seems also to be an essential ingredient in becoming a high-performance team, and therefore a deep understanding and commitment to succeeding at achieving success at meeting the goals each Sprint seems essential as well. This is another hard goal to achieve, in the same space of “breaking the sprint”, in my experience.
Arriving at the point where we are able to know, a week or two in advance, what functionality we will be able to deliver is a difficult one for several reasons:
– there is a factor of estimation, or predicting the future as you like to say, so underestimating the amount of work needed to deliver a piece of functionality is common
– the team initially may not be as cross-trained as needed to be able to work on any task in the Sprint backlog
– they also might not buy-in that the goal, of taking on exactly the right amount of work at the beginning of the Sprint, is a worthwhile one
– team members taking on BIs that were not accepted into the scope of the Sprint during the week, before completing the BIs that are part of the current Sprint
Those are the reasons I’ve come across for why it has been hard to meet the deliver on the scope of work defined for a Sprint. Can you speak to any of that? Or have you written somewhere about that aspect that you can link to?
Thanks in advance!
Meeting commitments is definitely a part of Scrum, but it’s not a “rule” per se. The team plans the Sprint collectively (which is a rule) and should make a commitment both to the work and to the stakeholders.
Your comments about it being difficult to know the future are well-taken!
Help, I’ve been informed and I can’t become igaronnt.
Thanks Dan,
All of the reasons that you have listed are very common characteristics of immature Scrum teams and organizations. It often takes a great deal of effort to overcome these cultural challenges. Indeed, there are no shortcuts or formulas. The team and the organization need to constantly make effort to learn to apply the rules of Scrum and trust that this effort is conducive to growth. Without effort, it will not be achieved. Coaching can help to accelerate the learning if a willingness to be coached exists. The ScrumMaster must be firm about this rule.
However, under the circumstance where altering the sprint scope can help the team to better meet the sprint goal. The PO can negotiate with the Scrum Development Team to implement it within the Sprint duration
Hi. So, the sprint goal can be altered if agreed with he PO. Did I understand well? That is new for me.