Get certified - Transform your world of work today


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

Team empowerment

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.

Cross-functional teams

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.

Effective retrospectives

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.

Article Rating

Current rating: 4.4 (5 ratings)


Sunita Katkar, CSP,CSM, 1/29/2016 11:29:32 AM
Great Information!
Anonymous, 1/30/2016 7:44:29 PM
Great article! I especially enjoyed the piece on Team Empowerment. Our scrum team constantly struggles with deciding between consuming stories they can confidently deliver in a sprint or give in to demands from management to consume more, ultimately causing team burn out. I will be sharing this article with our scrum master.
Mike Dwyer, CST,CSP,CSM,CSPO,REP, 2/2/2016 9:59:02 AM
Thank you for this article. As teams mature, gain confidence, and experience working together, velocity often seems to shrink. That is often not the case. Many times it reflects a team's maturity and understanding of the product outcome. For example a newly formed team of strangers may point a story requiring a report suite as too big to do in a sprint. After doing several reports for the product the same team may assign smaller points to the same work or combine work and give it the same pointing as the original.
The risk you take stabilizing velocity is the team no longer uses points to tell the Product Owner how "Big" a story is. Instead it starts viewing Story Points having meaning and value beyond communicating the unitless number we call Story Points.
Deadra Townsend, CSP,CSM,CSPO, 2/3/2016 3:18:57 PM
Thanks Mike. This article is intended for immature scrum teams trying to stabilize velocity and then work towards improvement.

I've worked with teams who worked on multiple small projects, that are totally unrelated. The things listed above really helped us stabilize velocity and then work towards improving.

I appreciate your feedback.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up