want to clear few doubts about the the article I read
Hello all,
I have few doubts about the points mentioned in below article which I thought to clarify with you.
The 9 stances of terrible Scrum Masters | by Todd Lankford | Serious Scrum | May, 2021 | Medium
The article says- :
Here are a few examples of bad habits misguided Scrum Masters bring:
- Setting team stretch goals
- Assigning velocity targets per day per developer
- Having the team commit to Sprint Backlogs <<------- Is this wrong practice ? Team should be committed about sprint backlog right?
- Measuring committed versus actual points <<------This is also a doubt
Also, the last point- : Measuring committed vs Actual story points is wrong practice as per the article. I am aware that we should not give much importance to story points beyond using them to estimate how much work we can take up. But as a metrics, in our team we do measure. In fact our agile coaches ask for this metrics periodically.
Perhaps Sprint Backlogs, and any estimates that are made, represent forecasts rather than a commitment. In a complex and uncertain world in which emergence provides critical advantage, it may be better to commit to achievable goals rather than to a forecast about what we think is involved.
As per the scrum guide, the sprint goal is the commitment by the developers. The guide does not say that they are committed to the sprint backlog.
Scrum team performance should be measured by the value that is delivered in each increment, and not by how well they forecasted their work.
Both of these are related.
The team doesn't commit to the Sprint Backlog. The Developers commit to the Sprint Goal. When I work with teams, I encourage the Sprint Goal to be achievable by completing on a subset of the Sprint Backlog. This helps the team to be able to focus on completing the Sprint Goal without necessarily completing every item in the Sprint Backlog.
Measuring committed versus actual points is similar - it implies that the team commits to the whole Sprint Backlog rather than a Sprint Goal. As the team is doing work, they may find that some of the work is no longer relevant. They may also learn that they underestimated or missed work required to achieve the Sprint Goal.
Committing to the whole Sprint Backlog as well as measuring committed vs actual points also indicate an emphasis on outputs rather than outcomes. The Sprint Goal represents outcomes that the team enables.
Hi,
1. About Having the team commit to Sprint Backlogs <<------- Is this wrong practice ? Team should be committed about sprint backlog right?
You can read full explanantion in Scrum Guide:
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
Sprint Backlog is a plan - not commitment but only forecast
Sprint Goal is commitment - the real commitment for a team
2. Measuring committed versus actual points
Commitment is a strong formulation of what the team wants to achieve, comparing it to speed, points or other indicators is not meaningful and even unfair.
I think the better way is to focus about product value in sprint.
Brilliant explanations.. This forum is unmatchable when you have dilemma or query about certain practices.
Thanks to Ian, Scott, Thomas, Powel for your valuable inputs.