Capacity vs Velocity

Last post 03:08 pm August 18, 2016
by Alan Larimer
3 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.