Capacity vs Velocity

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.

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.

@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

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

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?

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.

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.

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.

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.

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.

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.

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.