Capacity & Velocity — is there a connection?



Being a new methodology, Agile obviously comes with its own terminologies and nomeclatures. But these are not necessarily something that we already do not understand.

What is needed is for our minds to understand the mapping of what terms mean in the new methodology to what it meant in the older ones we used. We will discuss Capacity & Velocity today, which are two important but not difficult to understand terms we need to know when it comes to implementing Agile within our teams.


This term refers to the amount of available time for a planned iteration or release. While an iteration is generally shorter, a release spans approximately a quarter. Please note that release here does not mean a software delivery that we make to our customers or internal or external teams. It rather refers to a cycle or a timeframe which may or may not conclude with a formal software delivery.

Let us take a simple example of measuring capacity across an iteration length of two weeks. So here to compute capacity for a particular scrum team, we simply take the number of team members, assume their availability is the industry standard of 8 hours a day, and subtract the number of hours anyone is not available in the office on any given day due to any reason.

So assume a scrum team has 7 people for 2 weeks. This makes it 7 people x 10 working days = 70 man days of availability. Also one person is on planned vacation for 2 days. So the total capacity available is 70 md — 2 md = 68 md for the iteration in question.

The capacity can be further subdivided into different buckets as per the allocation in the scrum team. Generally the allocation spans across development and QA bucket, customer service bucket (for legacy or support activities), team overhead bucket and engineering enabler bucket (prototyping, or POCs to decide on a tangible course for actual future work)

So if there is a plan for allocation to follow 10% overhead, 20% enablers, 20% customer support and 50% dev + qa, then the above example will have 68 md divided approximately across with these percentages. We sometimes cannot get an exact number, but that is not an issue since what we need is to know roughly how much time to spend on what type of activity.

In the above picture depending on the size of the shoe only a particular size of foot can fit in. The capacity of the shoe is to only allow a particular size of foot and not more.



This term refers to the amount of work done by scrum teams. Before discussing this term in greater detail we need to first understand the notion of Story Points in Agile. Both the term and the usage across a broad range of projects of varying nature and real world applications makes Story Points a rather cumbersome term to understand in Agile.

Due to this situation, we once again do what Agile preaches — keep matters simple to understand. Story points are a range of specific numbers that are generally not sequential, which provide weights to implementation of different requirements/activities defined in the backlog based on the difficulty level to implement them. I will discuss Story Points separately in a different post but for now the understanding that its a grading of backlog items is enough for proceeding further

Coming back to Velocity then it simply refers to the amount of story points that the team is able to crunch within an iteration. One has to bear in mind that Velocity

  • differs across scrum teams
  • will differ across iterations for same scrum team due to different requirements and implementation challenges in each iteration
  • cannot be used to compare different scrum teams on their efficiency
  • needs to be measured across a minimum of three iterations to have a decent sample on which we can figure out what amount of work a scrum team is able to complete in general each iteration
  • should be used to discuss with scrum teams on how many story points worth of work they can take up each iteration — given their past record of completion across three iterations
  • will differ if composition of team members is changed at any point
  • if varied drastically across a particular iteration (sudden increase or decrease) should act as a trigger for a detailed retrospection at the end of the iteration to ensure that there was a valid reason for the variation

There are a few important things to then discuss on the relationship between the two metrics Capacity and Velocity.

  • Are they really related?
  • Does it help for planning or execution if we relate the two terms?
  • Can one be looked at independent of the other and still help for any part of Agile process?

Somewhere along the route of Agile gaining popularity, since many companies were unable to really understand specifically how Story Pointing is done, there was an approximation done that any work that takes 1 man day to implement is to be considered as 1 story point in terms of weight.

Unfortunately this has brought about a lot of confusion in the way teams use capacity and story point estimates which further lead to wrong velocity outcomes.

Capacity and Velocity are two independent metrices in Agile. However they help by coming together on a common platform to aid planning and execution aspects of Agile projects

  • In order to understand how many man days are totally available per release cycle of say 3 months, capacity figures help get this information
  • When each user story is estimated in man days for completion, this is further mapped against available capacity to understand how many stories can be attempted in an iteration or an overall release cycle
  • Since each user story also carries story points based on the weightage it gets in the overall backlog, knowing how many cumulated story points that is going to be taken within an iteration or even at a release level of 3 months will help compare that information with team velocity information. For example if a team’s velocity that they can commit to is 100 points, and a set of 10 user stories consume 136 man days for these 100 points — going by our previous example we have only 68 man days that worth of stories we can take up. So taking up double the effort is not okay. So we need to knock off stories from the sprint backlog until they reach 68 man days or less. This does not mean the new story point cumulative figure will be 50, it maybe higher. Agile always says we choose higher business value first. So higher business value also in a way means more weightage and more story points. So it is quite possible to have 68 man days worth of effort which gives 75 points instead of 100. So if team completes these stories, the velocity is likely to dip to 75 this time from the mean of 100. So there is bound to be a new mean then next time.
  • Capacity and Velocity has to be consdiered together and these metrics will have a profound impact on the way backlog is defined, on the way people commit to stories in an iteration and in general plan for an upcoming release as well.

This has been a rather lengthy discussion already, but we will continue speaking about these terms in greater detail in other posts with more explicit and specific scenarios.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s