Calculating Velocity what is best way?

1. I agree but depending on the age of the team and length of the sprints, I would likely extend that to 3-4 sprints. For a mature team, 2 sprints should suffice but for the average team, I think it is too few to consider.

2. We don't inflate the velocity in that manner, we just remember that the reason it was so low is because half the team was on vacation. Adding inflation in this case would be helpful for planning, but the actual velocity for that sprint should remain at 20. In other words, you've consistently delivered 40 points for the last 5 sprints with the exception of this 1 sprint. Well, you know the reason for the drop in velocity was only because of the drop in capacity so planning the next sprint for 40 points would be expected. However, in reporting the team's progress sprint over sprint, the velocity for that "low sprint" should still be kept at 20.

3. While I see the point, you're trying to improve your performance as a team; seems that you should just switch over to hours if you're going down that hole. Whether you're working up a conversion chart of sorts so that you know 1 story point = 2 hours, 2 SP = 3.5 hours, 3 SP= 5 hours and so on, or you're just using hours as the estimation value; you're doing the same thing but calling it a different name.

Thanks Curtis. I think in point 2, we will consider capacity (available hours) along with velocity to forecast future sprint and will stick with the actual velocity per Sprint as the true infromation radiator. I got more information from this forum to help understand the difference.

https://www.scrum.org/forum/scrum-forum/7293/capacity-vs-velocity

And point 3, yes. By trying to relate Story points to hours we are ending up measuring it in absolute terms indirectly. We will drop that practice. 

We have been using points per hour

Unless you are providing “Done” releasable value every hour, that measure is unlikely to be appropriate.

Bear in mind that the whole reason for estimation, including story pointing, is to help a team get its arms around how much work it can take on before making a delivery.

I was coming to chime in tangent style but sounds like you got your answer. 

Dan ,

What did you mean by tangent style?

I read that it's better to use velocity from recent sprints only (2-3) to account for the changes in the type of work and the team performance that may have improved or decreased (due to change in team members etc). I agree with this approach. 

There are different opinions out there with regards to how many sprints should be taken into account. Three seems to be the lowest number I've encountered so far, while eight seems to be the highest I've seen. IMHO it may also depend on Sprint length. If you have one-week-Sprints, three sprints may cover someone's summer vacation, while with four week sprints, that is rather unlikely.

While calculating velocity if we do not consider the number of hours that the team spent are we losing the correct insight? For example if half the team is off for one sprint and the story points delivered have dropped from 40 to 20, would we consider the velocity to be same or half? In other words would you call the velocity is points / hr or points/ Sprint? We have been using points per hour and producing functionality close to our forecast without problems. 

It would be unwise to ignore the impact of the team's capacity on its velocity.  You are correct in assuminig that it should be taken into account. But again, opinions of how to do it may differ. There is unlikely to be a "best practice" approach that fits all teams, so some experimentation will be needed to find out what works for your teams.

Points per hours, seems a bit excessive to me (as Ian also pointed out). Is that number greater or lower than 1? And how big are your stories on average? You should also bear in mind that velocity is, in essence, derived from estimates. So you shouldn't do super-precise calculations with it.

For the teams I've worked with, looking at days (or at max half days) of capacity and relating the velocity to that seemed to work well enough. Scrum Inc. offers a nice spreadsheet you can use if you don't want to make the calculations yourself: https://www.scruminc.com/yesterdays-weather/

I think this will be most controversial :P. After each sprint we are trying to determine how much hours each of our stories actually took in hours to just retrospect what our 1 points and 2 points actually ended up in hours. We are using this information to determine any stories that can be dropped or picked half way through the sprint. Looks like the team is going down a rabbit hole by giving a value to the story point which is a big no as per the whole concept of relative estimation.

Huh. Well. I don't think there's anything wrong with checking how much time a story took you to finish. Relating that to the story's estimate might also be useful in order to identify any outliers or bad estimates. But I wouldn't put any more faith in in than that. But that's just my opinion.

I read that it's better to use velocity from recent sprints only (2-3) to account for the changes in the type of work and the team performance that may have improved or decreased (due to change in team members etc). I agree with this approach.

During my PSK training, although we were talking about throughput, rather than velocity, Daniel Vacanti suggested it is worth the team considering the context in which the data comes from.

For instance, if it's the first week of January, taking the previous sprint's velocity might be unhelpful if there were a large number of days off due to Christmas and New Year. It might therefore be better to use data from further back, if the team feels that's more representative.

While calculating velocity if we do not consider the number of hours that the team spent are we losing the correct insight? For example if half the team is off for one sprint and the story points delivered have dropped from 40 to 20, would we consider the velocity to be same or half? In other words would you call the velocity is points / hr or points/ Sprint? We have been using points per hour and producing functionality close to our forecast without problems. 

Missing half of the team should be an exceptional circumstance. So in my opinion, any velocity calculation is of very limited use. If team members are really working together, I would be very surprised if the change in velocity is proportional to the absence of team members. It might be a useful thing to discuss in the retrospective, but I think trying to mathematically account for it could actually get in the way of empirical judgement.

Perhaps it's best to record a velocity of 20, along with a note explaining why this particular sprint was unusual.

In the past, I have used a forecast checklist, which would contain questions like:

• What was the velocity in each of our recent sprints?
• Is anyone expected to join or leave our team?
• Is anyone expected to take time off, or are there any public holidays?
• Are technical issues likely to cause us any problems?
• Does our distribution of skills affect what we are able to get to "Done"?
• Do we anticipate depending on anyone outside of the team?

The Development Team could then use this during Sprint Planning, prior to making a forecast.

It requires that velocity is treated in a consistent way, but encourages the Development Team to use their own judgement, based on other factors they consider to impact the forecast. 

In my practice, I like to use rolling averages of 2, 4, and 8 sprints to come up with 3 separate velocity values.   This provides a little more clarity and guidance to the team when coming up with their forecast.

For example, say that their 8-sprint velocity is 18, but their 4-sprint velocity is 20, and their 2-sprint velocity is 24.

There could be a number of reasons for the increase (capacity being one), but let's say in the team discussion that they identified a new initiative they started a few sprints ago, and their increase was somewhat based on that focus and synergy of items.   If the "offer" involves similar work, the team may conclude that an acceptable forecast for them is in the low 20's, as opposed to the longer-term velocity in the high teens.

When it comes down to it, a lot of estimations and forecasts involve context.   Be sure to represent that in your evaluations and planning.

• Is anyone expected to take time off, or are there any public holidays?

Simon, 

The biggest problem here s this is a constant unknown. We half at least 30-40% of team who is  cross allocated and often times are completely absent for consecutive days working on entirely different project. Under these circumstances how useful is this velocity? And would it be better to fix the team attendance and construct a DEDICATED team before even considering velocity as a reliable measure ?

That certainly does sound like a problem that needs to be solved.

Otherwise, how can anyone expect realistic forecasts from a Development Team with such major barriers to working together and focusing on a single goal?

Are the Development Team trusted, allowed, and encouraged to fully self-organize?

Hi,

To answer your 2nd question, you should of course consider capacity while calculating the estimated velocity. This is called focus factor and it's actually just simple math. For example:

Sprint 1 - Capacity: 400 hours / Actual Velocity: 50

Sprint 2 - Capacity: 300 hours / Actual Velocity: 35

Then the estimated velocity for the next sprint should be 48.5 not 42.5 

While this is useful and I do calculate this, it's the team who gives the final decision based on their experience.

Capacity is an important factor to consider especially when someone at senior level is looking at velocity of different teams (of similar size) in one report.

We half at least 30-40% of team who is  cross allocated and often times are completely absent for consecutive days working on entirely different project. Under these circumstances how useful is this velocity? 

In my opinion, velocity is still useful but only if you do not do anything to adjust for the shortage of people's time.  Report the actual velocity that the team is able to do because your organization is promoting the problem.  

One thing that I have heard many Agile Coaches say. 

Agile won't solve all your problems. It will just make them more apparent.

You have a problem with the individuals being assigned to more than one team.  Make it obvious by showing the real numbers.  Size stories correctly.  Plan sprints based on what the team feels they can accomplish.  Use actually velocity to arrive at your sustainable pace.  Don't try to make up ways to influence the numbers to look better.  Be transparent with the actual data. 

And would it be better to fix the team attendance and construct a DEDICATED team before even considering velocity as a reliable measure ?

I don't think so, but it definitely will improve velocity if you can construct a dedicated team.  In fact, it will probably increase productivity because the individuals will not be context switching.

And would it be better to fix the team attendance and construct a DEDICATED team before even considering velocity as a reliable measure ?

I have found that dedicated teams are probably best given they can focus and commit. That's when you can adequately track and use velocity. To be clear, I'm not saying that, in all other setups (without dedicated teams) you can't track/use velocity.

Capacity is an important factor to consider especially when someone at senior level is looking at velocity of different teams (of similar size) in one report.

Amit, what exactly are you referring to by "in one report"? Sometimes I think I'm lucky that in none of my positions, nobody pushed to get reports of different teams' velocities, story points delivered, and the like.

If you've been practising Scrum (or, in general, been in an agile environment), you'll know velocity should be used for planning purposes. Not for managers to compare team's historical performance, to compare team A with teams B and C, and so forth.

I missed the "one report" thing.  I have posted in this forum multiple times why I have problems with velocity as a measure of success.  Velocity is based on estimates.  Estimates are based on guesses.  Each team will come to their estimates in different ways.  So how do you compare them across teams?  That is like saying one team's velocity is G, one team's velocity is 28, another team's velocity is Apple.   They are completely different things that can't be compared.

Instead of comparing velocity across teams, compare value delivered.  How frequently is each team delivering value to the stakeholder?  How high is the value being delivered by each team on a frequent basis?  How happy are the stakeholders for each piece of value delivered?