On Scrum teams, velocity represents how much work a team can do each sprint. For example, let’s say a team takes eight user stories into the sprint. Out of the eight stories, four of the stories are 5 story points, and the other four are 3 story points. That means the projected velocity for that sprint is 32 (four stories at 5 points totaling 20 points, plus four stories at 3 points for 12 points. Add them together for a total of 32 points). At the end of the sprint, if all four of the stories worth 5 points are completed and three of the 4-point stories are completed, then the actual velocity for the sprint is 29 points.
As a team, we want to stabilize our velocity over time. For example, if a team had an actual velocities of 32, 35, 33, 37, 34, 36 across their last five sprints, that’s relatively stable. The trend shows the team’s velocity is roughly in the mid 30s. It generally takes three to five sprints to establish a relatively stable velocity. However, some teams never seem able to. For teams that can’t stabilize velocity, it’s due to one or more of the following reasons:
- People constantly coming in and out of your team – If you have people constantly coming in and out of your team from sprint to sprint, you don’t have stable capacity, making it difficult to stabilize velocity.
- People spread across multiple teams – If you have team members spread across multiple teams, you might have them 50% of the time on paper. However, it’s never really that simple. Sometimes the team member’s time is split 70-30, or 60-40, or even 80-20, and it tends to vary from sprint to sprint. Once again, varied capacity makes stabilizing velocity a challenge.
- Your PBI is too big – If your product backlog items (or user stories) are too big, this usually means the team starts the PBI in one sprint and finishes it multiple sprints later.
- Your sprint is too long – It’s harder to control scope and manage stakeholder’s expectations as your sprints get longer.
- Unstable environment – If your team is constantly stopping their planned work to address defects or stability issues in the product, that will wreak havoc on your velocity.
- Constant changes in priority – It’s hard to complete any work if priorities keep changing whenever the team starts working.
- Too much responding to day-to-day requests – A team can’t stabilize their velocity if large parts of their day are spent doing daily operational work.
Now, here’s how we can fix these issues:
- People constantly coming in and out of your team – Reduce the need to have people constantly coming in and out of our teams by prioritizing Scrum teams having the skills needed to build the product from the start.
- People spread across multiple teams – Move away from having your people spread across multiple teams and toward having them on one stable team so they can completely focus on the valuable delivery of product.
- Your PBI is too big – If your PBI/user stories are too big, then break them down into smaller pieces. My recommendation is that if your sprints are 2 weeks or longer, the largest PBI we want is about 4-5 days. If one is that size, everything else should be smaller. If your sprints are a weeklong, no single PBI should be larger than about half your sprint length.
- Your sprint is too long – If you’re doing 4-week sprints, try moving to 3-week sprints. If you’re using 3-week sprints, try experimenting with 2 weeks.
- Unstable environment – To quote a great thinker, Lightning McQueen from the movie Cars, “sometimes you need to go slower to go faster.” If you are in an environment with lots of technical debt, you may need to spend a few sprints cleaning up and stabilizing the product before building new capabilities.
- Constant changes in priority – Make sure the Product Owner is strategically aligning the requirements and incoming stakeholder needs to the product goal and roadmap. When there are constant changes in priority, it may be a sign that the Product Owner is reacting to daily requests rather than working strategically towards the product’s goals.
- Too much responding to day-to-day requests – This one is interesting. If your team is supposed to be responding to day-to-day requests as a major part of their work, they may want to consider using a Kanban based flow approach rather than an iterative incremental approach like Scrum.
If you’re team’s velocity doesn’t stabilize naturally throughout a few sprints, see if they are encountering any of the issues above, then try the recommended solutions.
To learn more about predicting and stabilizing velocity, as well as product nbacklog items and user stories, join one of our upcoming Certified ScrumMaster courses.