Capacity and velocity are both really important concepts in Scrum and can be applied in different ways. But what are they really? And as a Scrum master, what is the role you need to play to maximize both?

Once you're in a sprint, you'll have a bunch of tasks and stories and these will have all story points assigned to them by the team. These points are really important when it comes to thinking about velocity because velocity is the number of story points the team can get through in a set amount of time. Capacity, on the other hand, is simply the amount of time the development team have per sprint to complete their work. So, capacity is the limiting factor, the time that velocity is measured against. There are a few different kinds of velocity that you might be interested in.

First up, we have individual task velocity, how long does it take the development team to complete individual tasks. Because tasks and stories have been estimated relative to each other, you should have a good idea of roughly how long tasks should take. As a Scrum master, you need to make sure that you understand what is going on if tasks are taking much longer or quicker to complete than they should have.

Next, you can think of velocity at a sprint level, how many story points the development team can get through on average per sprint. This information is helpful especially during sprint planning. If the product owner is asking for work to be completed, but you can see that based on previous sprint velocity this is unachievable, you'll be able to stop the team from taking on more than they have capacity for.

The last kind of velocity is at the epic level or release level, how much of the epic has been completed. Before work on an epic begins, all of the stories that make up that epic should be included as far as the product owner understands. By tracking this velocity, you can also keep track of scope creep, when additional work is being added down the line. As a Scrum master, you need to hold the product owner accountable here to make sure that they're creating realistic epics at the start and that scope creep only happens because there is legitimate reason for additional requirements.

So, with all this in mind, there are two quick and easy formulas for velocity that you can use. Firstly, you have a formula for actual velocity which is the measurement for how quickly the team are getting through work. This is measured as the number of story points divided by the number of sprints they were completed in.

The second is for the expected velocity which is about how quickly teams plan to get through work. This can be measured as the total number of story points committed for completion divided by the number of sprints they were committed in. The difference here is that while the Scrum team will always only commit to what they believe they can complete in a sprint, they still won't always be able to complete this work. This happens because of blockers or because they failed fast and decided the work they had committed to needs to change for whatever reasons.

As the Scrum master, it's important for you to help the development team understand what their actual and expected velocity is as you always want to aim for these to be as close together as possible. And if you find that they're consistently over committing or being blocked by impediments, then you need to find a way to fix these. Great.

So, now we have a pretty strong idea of what the different kinds of velocity are and why they're important and how you can calculate them. Let's talk a little bit about some of the things that can go wrong with velocity. One of the common pitfalls is using velocity as a goal and not as a measurement of the team's progress. Remember that story points are ultimately subjective and don't equal an exact number of hours that a task will take to complete. Giving a team an exact number of story points they need to complete, every sprint can easily lead the team to being less productive as they still control the work they actually do. Velocity should be upheld and improved over time, but not at the expense of productivity.

Another common pitfall is to expect the highest possible velocity as soon as you move to Scrum. Your development team will take some time to find their rhythm. On top of this, it will take a few iterations before your estimates for work become more accurate so initial velocity might be all over the place.

As the Scrum master, you need to represent this to the product owner and to the wider organization and make sure that the development team have enough time to get into their groove. It can be tempting to think of work in bigger chunks, but you need to avoid this. Bigger chunks of work are features, not stories. Stories need to be granular and specific. So, if you find that the product owner hasn't created granular stories, you need to hold them accountable.

You also need to plan for some slack in every sprint. This isn't unproductive time. It's time used for team members to collaborate, work together and have meetings. If you fill up the sprint with more tasks instead of accounting for the slack, your team will become unproductive. Scrum masters must make sure that the Scrum team can work effectively which means the slack time must be protected.

So, what can you do to protect your Scrum team and make sure they don't fall into any of these traps? Use empirical data when estimating to make sure that the tasks are compared with similar work that has been done previously. Take your time in sprint planning to get as much detail as you can. As the Scrum master, you'll be facilitating the sprint planning. So, make sure everyone leaves feeling confident and ready. Build slack time into your sprints and take time after each sprint to make sure that impediments don't reoccur.

So, that's it for this video. There are a bunch of ways to think about velocity, things that can impair it and ways for you as a Scrum master to ensure that your team's velocity is stable and improving.

Velocity and capacity

About