Not taking actual average velocity for planning
Hi All,
As a scrum master, I check my team's velocity and share with them. However, my team is not ready to take the average velocity into account for planning next sprints and want to keep it to a lesser value, and then they always end up injecting more work as they have accomplished all the planned work, which effects all the reports and predictability is hurt. This has been repeating for the past 6 months...please advise.
Thanks in Advance!
It seems like this is a good thing for predictability.
Let's say the team's average velocity over the past 3 or 4 Sprints is 100. The team says that they can do 80. At Sprint Planning, they collaborate with the Product Owner, craft a Sprint Goal, and start pulling in the Product Backlog Items needed to accomplish that goal. The total is 80 or less. The Sprint Goal is valuable as it stands and increasing the scope of the Sprint Goal would require more than 80. The team commits to their Sprint Goal. And then they achieve that Sprint Goal. And then repeat for every Sprint.
They have predictability because, Sprint over Sprint, they are making a commitment to a valuable next step represented by the Sprint Goal and meeting that commitment.
I would recognize the team for acknowledging and managing the existence of uncertainty. Perhaps they underestimated some of their work. Perhaps someone will need unplanned time off. Perhaps a stakeholder will report a critical defect that needs to be fixed. Perhaps the Product Owner or customer will have a small, but higher priority request. The team has capacity to not only handle when these things happen, but also ensure that they can still regularly meet their Sprint Goal.
For me, the real question is if the team is able to improve. Is the Product Owner keeping the backlog well-ordered and has the team refined the work at the top of the Product Backlog so the team can pull in valuable work as the capacity arises? Is the team improving their ways of working to not complete 100, but maybe 110 or 120 and then start pulling in 85 or 90 or 95 at Sprint Planning? Is the team managing technical debt and maintaining the overall quality of the product? If so, this is good. If not, these are the places to look for improving.
As a scrum master, I check my team's velocity and share with them
That's the problem. You're tracking their velocity for them, and it seems that if you weren't, they wouldn't even know what it was. It isn't a Scrum Master's job to do such a thing. Developers ought to be self-monitoring.
My advice is to encourage them to know what their velocity is. If they have ownership of their metrics and measures, such as velocity or throughput or whatever, they might be more likely to take this data into account.