Capacity vs Velocity

Last post 10:03 pm January 22, 2018
by Daria Bagina
8 replies
Author
Messages
03:40 pm August 17, 2016

I'm currently the Scrum Master of a 10 developer strong team.

We've adopted Agile/Scrum methodologies for some time now and are currently on our 53rd Sprint.

Our stakeholders actively like to understand the output of story points in advance of a Sprint. This is currently done on a capacity basis working on a focus factor of 60%.

We have recently moved from 2 week Sprint cycles to 3 week Sprint cycles so that we enough breathing space to complete the governance for the production environment, resolve any bugs/issues within the additional time and tackle technical debt.

Our focus factor of 60% has been kept at 60% so where previously a dev was given 6 points to complete during a 2 week Sprint, the dev is now allocated 9points over the 3weeks.

There are growing concerns that we're not "successful" in the amount of points we estimate at the start in comparison to the completed points at the end of the sprint. We always seem to fall short especially given there is no true mechanism in JIRA to report this. The issue was more apparent during our 2week Sprints.

I've taken a Sprint Retro action to review this.

What are the views of Capacity planning vs Velocity planning?

If I've missed any key points. Let me know and I'll try and provide as much info as possible.

06:08 pm August 17, 2016

First of all, velocity is not a term used in the Scrum Guide. It is one of those things left to the team to decide what works best for them. Likewise, capacity is mentioned only twice in the Scrum Guide. And, focus factor is not in the Scrum Guide at all.

Teams that use velocity for planning typically base velocity ion the empirical observation of previously completed sprints. Capacity is based on the team's expected or projected future availability.

Velocity is based on actual points completed, which is typically an average of all previous sprints. Velocity is used to plan how many product backlog items the team should bring into the next sprint.

Capacity is how much availability the team has for the sprint. This may vary based on team members being on vacation, ill, etc. The team should consider capacity in determining how many product backlog items to plan for a sprint. The team may want to consider taking on fewer product backlog items if capacity is expected to be less for the sprint. Likewise, if more team members are recently added, the team may want to take on more product backlog items.

Velocity should only be used for the team for planning purposes. The success of the team should always be based upon the delivery of value--i.e. a working increment of the product delivered to the customer.

10:07 pm August 17, 2016

Our stakeholders actively like to understand the output of story points in advance of a Sprint.

What do you mean by this statement? Velocity can be used by Product Owners to gauge how many PBI's may be completed by a point in the future (if the PBI's contain a preliminary story point estimate).

In no way should there be any attempt to equate story points to an individual development team member's productivity, or to equate story points to a time duration. That is a complete misuse of relative estimation.

so where previously a dev was given 6 points to complete during a 2 week Sprint, the dev is now allocated 9points over the 3weeks.

Why are you concerned at all with what an individual development team member does during a sprint? As a Scrum Master, your primary focus should be around team productivity, and associated metrics if needed.

There are growing concerns that we're not "successful" in the amount of points we estimate at the start in comparison to the completed points at the end of the sprint. We always seem to fall short especially given there is no true mechanism in JIRA to report this. The issue was more apparent during our 2week Sprints.

Often, sprint lengths are increased to "hide" the inefficiencies and pain points uncovered through shorter sprint lengths. What were the reasons around the organizations inability to complete release-related items during a 2-week sprint? Or the team;s inability to remedy bugs found during a 2-week sprint?

Perhaps you are the Scrum Master for a team that has been trying to work under Scrum for over two years now (53 sprints), but I gather just from your statements that there is a lot of Scrumbut going on, and you're still experiencing a lot of the pain associated with it.

03:08 pm August 18, 2016

The success of the team should always be based upon the delivery of value--i.e. a working increment of the product delivered to the customer.

FTW

Working software is the primary measure of progress

Businesses and customers always want more and faster. The goal of the Scrum Team's work and the focus of conversation needs to be that: valuable, completeness, quality, tested, etc.

06:13 pm January 22, 2018

My team came down to two week sprint instead for four week. How can I calculate the team capacity and see the difference in capacity from four to two weeks

09:42 pm January 22, 2018

Shweta, how are you currently calculating team capacity?  

09:48 pm January 22, 2018

@Shweta, you can calculate Average velocity per developer per day, though it will require some backtracking on number of working days and days off anyone took recently. The first setup of this needs some manual work. 
We currently use this to plan our sprints since we had some team changes along the way. In our case we also take previous sprint's velocity into account.

Basically your Velocity per developer per day would be Story points completed in the sprint divided by Number of peopledays, and Peopledays is Working days * Number of team members - Any planned days off or vacation or business trips

09:49 pm January 22, 2018

Why are you trying to do this? Are the team uncomfortable estimating how much work they can take on?

10:03 pm January 22, 2018

Ian, not sure if this question was addressed to me.

My current team is driven by numbers, especially Team Lead. As I see it, it helps them make initial decision on what amount of work they can take in. From my side - it is a great reminder for us to look at our capacity for next sprint as it is immediately calculated in our planned velocity for next sprint based on peopledays. 

However, even if we use this in planning initially, I always encourage the team to look at the work planned and decide whether we can actually complete and whether we can take on more (committment based planning). 

So even if we use velocity, we still look at committment.