Capacity vs Velocity

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.

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.

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.

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

Shweta, how are you currently calculating team capacity?  

@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

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

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.

@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.

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

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?

+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).

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!

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.

@Daria Bagina, really not sure how to respond to this.

Maybe your situation demands you track in this way but this is an anti-pattern in my opinion

@Mahendra Hotte again, where is this coming from? This has all the hallmarks of PRINCE2 and/or PMI project management.

Unfortunately SAFe has nothing to do with 'agile'

I'm going to start by saying that the only person in this thread I agree with is @Ian.  Do not mean to offend anyone but reading this thread made me check to see that I was in a scrum.org forum and not a Project Management one.

So, here is my opinion on all of this.

Velocity is not a measure of productivity because it is based on a purely made up relative estimate of story points. A really simplified definition of story points is a estimate of effort/work in relation to other things.  It has no correlation to time or capacity.  Velocity is more of a measure of the teams ability to accurately guess at the amount of work they can do over time than anything else. 

Throughput is an actual measure of how much work a team can do during a time box.  It is based on the actual stories that are done. But throughput of a single sprint is useless. You have to take the measurement over a series of time boxes in order for it to make sense.  You say you have 53 sprints so you should be able to see how many stories are finished in each sprint and start to calculate your throughput.  But if you change your time box you are back to 0 and starting over.

Many of you talk about assigning items to individual developers, measuring their productivity and output. As Scrum practitioners, you are doing it wrong.  The team is responsible for everything in a sprint.  No one person is responsible.  The team has a measurable velocity or throughput, not an individual. I realize the scrum guide does not elaborate on the self-managed team thing but it doesn't take much internet trolling to come up with many definitions and none of them include individual efforts over team efforts.

In traditional project management, capacity is the total number of hours that an individual, or team, has to do work. In scrum, capacity is the amount of product backlog items that a team can satisfy during a time box without going to heroic efforts. Capacity is measured by the sustainable pace that the team can achieve and that is based more on throughput of product backlog items addressed instead of number of hours you have to work. 

To boil down the original post to the only scrum related problem I can see comes from this statement:

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 ...

The problem I interpret is that the stakeholders are not seeing value delivered in each sprint.  To me that implies that the Product Owner is not correctly working with the Development Team to break down Product Backlog Items in to slices of deliverable value added functionality.  If that was being done, then the Stakeholders would be less likely to be concerned about individual team members productivity. 

It could also indicate that the stakeholders are incorrectly identified. They sound more like managers that are concerned about employee productivity than individuals interested in the benefit being provided to them to solve their problems. 

Daniel, I'm not sure where you base your definitions on.

Velocity is not a measure for the ability to.. what you describe as average throughput is commonly known as velocity.

I wouldn't agree that the velocity/throughput of 1 sprint is useless.

What you describe as capacity: 'amount of pbi's' is something that is new to me. I don't see this defined in the scrum guide and I wouldn't assign any value to this metric..

Capacity is commonly used as the time team members have available for a sprint. Why not use it like this?

I think the initial question: capacity vs velocity is valid when looking at changes in capacity among sprints. Though it's clearly not OP's biggest problem in terms of scrum.

Let me clarify a bit and restate that this is all my opinions.  Velocity is based on adding up Story Points.  "We have a velocity of 30 points per sprint".  Since Story Points are usually done to estimate effort relative to other stories, in my opinion they are not a valid data point to predict how much work a team can do.  Estimation changes over time as the team gets better at understanding the problem space, as they get more in sync with everyone's abilities and contribution to the team. 

What you describe as capacity: 'amount of pbi's' is something that is new to me. I don't see this defined in the scrum guide and I wouldn't assign any value to this metric..

I use total stories completed, i.e. throughput, because I have found that over time that data point tends to be more predictable.  I borrowed it from other agile methods since Scrum is a framework in which you can incorporate any process which works best for your organization. Granted that can also change for many of the same reasons as estimation will change but I have found that is more accurate as a predictor.  I will admit that the scrum guide says nothing about it but neither does it state anything about using velocity.  It also does not say anything about how to predict future delivery dates.  It says that predictability is increased through inspection, adaption and transparency and that the Increment is released when the Product Owners decides. Team capacity is not mentioned in the scrum guide either but you seem set on using that metric.  Why is that when I suggest a metric that is not specifically mentioned in the scrum guide you immediately discount it but insist on using other metrics that are not mentioned in the guide either. I suggested ways that I have been successful in providing some "metric" to help the teams so that you could consider them as options.  I was not saying that it is the only way.

The original problem statement was about how to you tend to fall short on the estimation of work you can do in a sprint unless I misread it.  I offered an alternative. 

You state using a lot of standard project management measurements, all of which can be useful. It boils down to what your team and your organization wants to use. 

My problem with what you stated is more in terms of terminology than the way you work with a team.

"Capacity in scrum...", that's why I mentioned it's not in the scrum guide as you described, I don't agree with your definition there and it was new to me. It also doesn't combine well with how "capacity" is used in other phrases in the scrum guide.

I think available teammember time is an important input, since changes in team (time available) can have a big impact on outcome.

Velocity is indeed just another input, but I don't really understand your argument against it. I think it has more value than stories amount completed (throughput/capacity/?). The latter is only effective if you split up stories pretty evenly. If a team has problems estimating outcomes, this isn't a very likely scenario.

That velocity changes over time is not a reason to dismiss it, you could just add more emphasis on more recent sprint numbers, right?

That said, it could be a valid way to improve by splitting up more. I'm not against that at all. There is a risk in overdesigning there though.

@Norbert  I agree with everything you just said.  In reality there is nothing in the Scrum Guide that actually gives us any real idea how to do any of this.  And that is on purpose.  The process is intentionally avoided to keep it as a framework.  The people doing the work get to define the processes and these kind of measurements are process. 

The Scrum Guide only mentions capacity twice.  Once as an input to Sprint Planning and once in relation to backlog refinement. But in no place does it explain how to compute it.  In truth how ever the team/organization decides to define "capacity" can be applied in both instances as long as it is consistently applied/calculated.

My use of throughput is slightly different. I took it from Lean and Kanban with some tweaking of my own based on some experimentation. I have found it useful and somewhat accurate in most cases. But it won't fit every circumstance.

Good luck with your situation.  I hope you can work something out that works for you. 

@Daniel Wilhite,

Velocity and throughput are in a way similar. While practicing scrum I do no think specifically measuring throughput helps. Here's why, both velocity and throughput are bound to experience fluctuations, but as a general rule we use the average of 3 sprints to determine a stable average velocity/throughput to base our planning efforts/forecasts on. Assuming a 1 point story has the same DoD as a story used in the context of throughput, then when looking at averages i.e. stories/sprint or velocity/sprint the outcome is similar.

I do not see how some folks still worry too much about story points. I hear these kind of statements like 1 developer got too many points, I didn't get enough points, not enough points for the sprint,  etc and why no one understands that story points have no value whatsoever other than being used for planning. for ex: if average velocity of 3 sprints in 40 points, then you can most likely tackle for ex: 10 x 1 point stories + 10 x 3 point stories = 40 points. Instead the focus should be more on delivery value or functionality or a piece of working code that helps the stakeholder or the end user in some way.

In my opinion, I disagree that velocity i.e. story points completed have more value than stories completed. The way I see this, it is the same thing. ex: if you have a story that is 3 points (remember, this 3 points constitutes your overall velocity) and the story is incomplete at the end of the sprint, how can you compare that to a story that is completed if the context is about measuring using throughput i.e. stories completed per specified iteration?

Scrum does not mandate the use of story points or velocity, then I don't see why throughput can't be used as a metric as opposed to what every other organization commonly practices i.e. velocity and story points.

Please feel free to have a discussion or correct me if I am wrong. This is just my opinion and understanding.

Nobody said you can't use nr of completed items, you can.

I just don't like it in general cause you're using less information to base your planning on than with velocity with no real benefit.

I don't understand what incomplete items have to do with this comparison.

I just don't like it in general cause you're using less information to base your planning on than with velocity with no real benefit.

Could you elaborate how less information is being used if throughput (stories/sprint) is used vs. velocity (story points/sprint)?

You miss out on the estimated effort, which has great impact if the sizes of your stories vary a lot.

In referring to Velocity and Throughput, I do not see either of them as a valuable metric in determining business value delivered, which is the main goal of any Agile framework.

I do see Functional Points, or some other value-based metric, as much more applicable than Velocity or Throughput.   I can have a Team deliver 50 Story Points on average each sprint, or 20 stories each sprint, but that doesn't tell me anything about whether they built something that delighted the customers or not.

In my company, we use a Weighted Shortest Job First formula to both represent prioritization and value.   Not perfect by any means, but it does improve visibility around business value delivered.

I actually like the way this discussion has turned out.  :)  It points out that there is no right way to do this, just as Scrum intends.  I like to tell my teams that there is no right way, there is just the right way right now.  When trying to measure/predict a teams productivity, I honestly would choose to do nothing. I agree with what @Timothy Baffa says about we should be measuring the value delivered. I've seen many teams with a high velocity that seldom delivers value from which the end user benefits. 

@Ibrar Ahmed In the end, find the "measurement" that works best for your teams and company.  There is no right answer.  All any of us can do is provide you an opinion and some suggestions that work for us. 

Good luck.

I completely agree with Daniel and Ian.

You can not assign points to individuals just like you can not use points to calculate productivity.

Sure, there are many ways to go about and indeed Scrum does not prescribes any specific way. However, calculating things like capacity, velocity and productivity based on what an individual team member accomplishes or how fast a team member can turn things around is not only time consuming but does not truly correlates to the relative values that get collected during a grooming session.

Daniel, I liked your answers but recently I have been questioning by Upper Management about the Velocity of the team at the time I am providing Sprint Mid and End Report. Given a situation, where we had to carry over some pending work to the next sprint due to requirements changes by end-users. Justifications for carryover items were provided in the reports as transparency. I understand Upper Management have reasons to ask these questions as they are equally concerned about the team performance and to make sure Scrum team is estimating the work correctly. How would you handle these situations?

I understand Upper Management have reasons to ask these questions as they are equally concerned about the team performance

Are Upper Management aware that emphasizing velocity rather than value delivered, and supposed Sprint carryover rather than Sprint Goals achieved,  is quite likely to inhibit team performance?

@Ian stole my thunder.  

It really doesn't matter how many Product Backlog Items are being completed in a Sprint if the results are not providing value to the stakeholders.  And focusing on how individual team members are producing work will always end up in them doing a lot of work but that work may not produce any value.  For example, if the Sprint Backlog contains 12 items but each item represents something that is completely disconnected from all of the others, it is very likely that no value will be seen by the stakeholders. 

You do not specify how "velocity" is being calculated or what your upper management believes it means. Those are very important aspects. You did say that the upper management is concerned that the "Scrum team is estimating work correctly".  Do you know why that is a concern?  Why aren't the more worried about the Scrum team completing work that the stakeholders find valuable? 

Remember that an estimate is done before any real work is done and based upon the information that is available at that time.  As soon as work begins, new information is discovered.  That new information could lead to more complexity or less complexity. An estimate is only good for the point in time at which it was created.  For example, if someone asked you how long it would take for you to drive from your house to a different city, you could estimate it as 2 hours.  But when you start the trip you encounter an accident that has closed lanes of traffic.  Or you encounter road construction that you were not aware of.  Or you experience car trouble and have to stop for a repair.  Or you find that the road is relatively free of traffic and you can progress at a faster pace.  All of those impact the trip in various ways.  But until you start the journey, you will never know these things.  Estimates are a point in time guess.  Personally, I have a difficult time measuring anything based upon guesses. 

As a Scrum Master you have an opportunity to work with the upper management to help them better understand how value is a better measurement than estimates. You might want to read the Evidence Based Management Guide here at scrum.org.  It might also be a good idea for your upper management to read it.  It may be a way to help everyone focus on what really matters...the value of the work.