Capacity vs Velocity

Last post 03:10 pm March 23, 2018
by Mahendra Hotte
14 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.

04:00 pm January 23, 2018

@Timothy  This is how I look at the capacity and calculate

  1. Multiply the number of workdays in the period by eight (hours per day) to get the total number of “Work Hours” hours in the period.
  2. Subtract the total time allocated for whole-team meetings. This result is the “Net Work Hours,” and is smaller than the total “Work Hours.”
  3. Get the availability and time off for each person. For each person, subtract time off from Net Work Hours, and multiply the result by his availability to get his individual capacity.
  4. Add up the individual capacities to get the Team capacity in person hours, and divide by eight to get the capacity in person-days.
  5. Divide the Team capacity in hours by the Work Hours to get the Net Team Resources, which is the effective number of full-time people on the Team.
04:01 pm January 23, 2018

@Ian - Yes many times Developers would complain about the additional points assigned to them

05:03 pm January 23, 2018

Yes many times Developers would complain about the additional points assigned to them

I’m not surprised. Do you think it is reasonable to calculate and assign points to team members, and in keeping with the principles of Scrum? Shouldn’t they be responsible for their own estimates and how much work they take on each Sprint?

02:23 pm January 24, 2018

+1 Ian.

In addition Shweta, there  should be zero assigning of anything in Scrum.   It is up to the entire team to assess the offer of work made by the PO, and determine whether they (as a whole!) can forecast completion of that work according to their Definition of Done.

I also help my teams assess their capacity, but my approach is more lightweight than the one you use.   I take the number of Development Team members, multiply by the number of days in the sprint, and multiply by 6 hours (not 8) to allow for slack (unrealistic to plan for direct 100% allocation to sprint items).   Then from that hour total, subtract any time for team member PTO, time in Scrum Ceremonies, and time for other meetings.   

This number along with the team velocity, are only used as guidelines to help the team assess what they may be capable of.   These are their planning metrics (although the PO may also use the team's velocity to project potential completion dates).

10:01 am January 27, 2018

It is recommended to have a histogram of the team performance, where not only velocity is tracked, but also other key metrics such as capacity (hours), actual hours, forecast, actual points (categorized into feature, debt,  technical investment - these are architecture/environment or other task that may help increase feature implementation or prevent debts) for a better forecast in the succeeding sprints. When these factors are seen together in 1 graph, correlations can be observed.

In the article below, you can find some template for the histogram 

https://agilepinoy.wordpress.com/2018/01/11/measuring-team-velocity/

Cheers!

04:51 am March 23, 2018

I use both Velocity (the number of story points delivered by the team) and Capacity (the sum total of the engg hours available of the individual members of the team). For capacity planning I consider 5.5hrs engg hours per person per day. So for a 10 member 2 week sprint the total will be 550hrs of capacity. https://www.scaledagileframework.com/iteration-planning/ - this page explains on pretty much the same lines in the section Establishing Velocity and Tasking Stories.