Stabilizing Team Velocity in Scrum
29 January 2016
What is velocity?
Velocity is how much work a team can successfully get done within an iteration. Velocity also helps to track how much effort the team has put into completing the work in a given sprint. Teams who know their velocity can plan future sprints more easily by predicting and monitoring their progress.
How to stabilize team velocity
Teams should feel empowered to take on only as much work as they feel they can complete in a sprint. No one should tell the team how much work to do and demand that they do it. The team should have a safe environment in which they can be honest about how much work can be completed and agree as a team to take on only what they can finish.
The ScrumMaster should make sure that the team feels empowered and that the members know it's their decision as to how much work can be pulled into the iteration. This means that the ScrumMaster will have to protect the team and shield it from outsiders, product owners, and management who might influence or pressure members to do more than they feel can be completed.
Groomed user stories
Backlog grooming will allow teams to ask questions about user stories and acceptance criteria prior to sprint planning, and also to play Planning Poker®. Most teams I work with prefer to add story points during backlog grooming instead of during sprint planning. This is a decision that the ScrumMaster can ask the team to make.
Teams also have the opportunity to ask the product owner (PO) questions and work with the PO to break down user stories that they feel are too big to fit in an iteration. This is a great time for the team to identify internal or external dependencies, which will help the PO prioritize user stories accordingly. ScrumMasters can also coordinate with other ScrumMasters to make sure that any user stories that are dependent on another team are prioritized in their sprints, to help limit roadblocks once the iteration begins.
Identifying dependencies early
Teams that identify internal and external dependencies during backlog grooming will limit roadblocks that they would have otherwise faced once the sprint begins. If ScrumMasters need to coordinate with external teams, they have the opportunity to do so. Some external dependencies can even be cleared before the sprint begins, if other teams are made aware sooner rather than later.
Teams that work together as one development team and don't always focus on individual roles are very successful at achieving sprint goals. If the sprint goal is in danger of not being completed due to testing constraints and another team member, whose primary expertise is not testing, can jump in and test, then the team member should do so. It's all about achieving the goal.
The retrospective is a great time to figure out what's not working, what is working, and how can things get better. Listen to the team! They are the ones doing the work. I encourage ScrumMasters to suggest that the team come up with action items for the things they want to see improved. This way, the retrospective does not turn into a forum for complaints but a place where the team is actually setting plans for improvement. I also encourage teams to talk about how they can improve task completion and successes, and overcome failures. And keep planning on how to get better.
Stabilizing velocity will help teams predict how much they can complete in each sprint. It will also allow for future sprints to be predicted more easily. Teams with a stabilized velocity will also have a higher sense of morale. Teams love to be able to set goals and actually achieve them consistently!
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.4 (5 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.