Velocity calculation and work with unfinished stories

The purpose of estimation is to help a team get its arms around how much work it can take on in a Sprint and finish to the “Done” standard necessary for release. That’s it. There is usually no value to be found in the business of being a story point accountant.

Hi Ian,

Thanks for your response.

Can you please explain in more details what exactly you mean with your last line - There is usually no value to be found in the business of being a story point accountant.

The thing that Ian is trying to point out is that velocity and story point estimation tries to give the team a feeling of what they think they can do and maybe some input on where to improve things. The discussion we're getting at in your question here is that it's starting to become some sort of mathimatical approach and has a wrong or wright kind of answer. So this goes way beyond what estimation tries to do. Scrutinizing on how story points are being used and if it's being done correctly will just drain energy and moves focus away from actually delivering value.

Hi Sander,

I believe with my question I am not challenging the aim and gains of story point estimation itself.

I my question I am asking about practical approach advice based on your experience with Scrum teams on which approach/practice works better (or maybe there is another practice I am not covering here at all) with aim to fulfil what Ian was referring to "to help a team get its arms around how much work it can take on in a Sprint and finish to the “Done” standard".

To paraphrase I am trying to understand what is the best PRACTICAL approach to work with unfinished user stories in sprints to work as a scrum master on the following aspects in my Scrum teams:

1) Transparency

2) Predictability

3) Work in small batch sizes

4) Meeting sprint goal

5) Continuous delivery

Sorry, I forgot one important point in previous comment:

6) Right mindset and behavior in teams for constant learning and improvement

Thanks for the further details! So here is what I commonly see happening (not saying it is the best approach, but might be helpful). If user stories are not finished, they go back to the Product Backlog entirely. The spent time and effort is discarded, as it is not "Done". The Product Owner decides what to do with it, discusses with the Dev Team on the probable remaining effort/time/complexity/uncertainties etc and prioritizes it again. After that it may or may not be pulled in during the next Sprint. In that sense one creates transparency, it get's worked on as small batch size, gives a good opportunity to inspect the predictability and if needed adapt to improve. Maybe looking at the lessons learned there, it helps to form challenging, but achievable, Sprint Goals.



I like the fifth point your asserting. Many times I see Scrum Teams actually forgetting this part, limiting ability to inspect and adapt on valuable feedback. Maybe it's not needed for every ST to have continuous delivery, but as you bring it up I assume you guys do. Maybe during a Sprint one or more user stories are deemed not to be able to get to "Done". Might it help there to split them up to the point that they would still be "Done" and independently deliver value?

Sander, I fully I agree with your last comment and have nothing to add from my side.

If we get back to my original post I believe that what you have written goes in line with my described first approach. From your point of view - do you agree that second approach I have described doesn't support these 6 points at same level first approach does?

I'm not saying one is better than the other, but I get the feeling that velocity in that sense becomes a "hard" metric and it sugarcoats the things actually being done. And blindly spilling over user stories, work items, whatever you use, into the next Sprint without inspecting them and deside how to act removes the opportunity to learn, to create transparency, to actually inspect & adapt. 

The second approach is quite common, and is sometimes a sign that the team perceive a high velocity as being somehow better than a low one. Could it be that velocity is reported as a performance metric, or that there is a culture within the team/company/region that maximizing the amount of work done is more important than maximizing the value delivered?

Personally I don't advocate using velocity, as I see story point estimations as more subjective than right-sizing items. Teams can tie themselves in knots, trying to work out how to record a helpful velocity, and I'm yet to see a single good mechanism for a team to go back to an item and inspect whether its story point estimate was reliable.

The best thing I ever learned from story points is that everything flows better when you only pick up small items, which brings me onto an alternative suggestion.

It is possible to eliminate velocity, and instead forecast with a combination of throughput and cycle time.

Right-sizing means you can count the throughput (number of items "Done") in previous sprints, and use that number to forecast how many right-sized items can be "Done" in the next sprint.

Cycle time is useful to support right-sizing. The team could define the right-size as being large enough to be possible to get feedback, and small enough that it can be completed within a certain number of days. The team can inspect how well they are doing this, by verifying whether the actual cycle time was within their estimate.

One typical result of this approach is that usually the teams will get many more, significantly smaller items "Done". Such that the discussion about how to count work-in-progress becomes much less relevant, as it would have a much smaller impact on the planning metric.

I like @Simon Mayer's suggestion and I actually coach that approach.  Velocity has no definition in the Scrum Guide.  It has become a formula of adding up Story Points because that is easy.  But that means you measuring based upon guesses which I really can't buy into.  I do use Story Points but as a forecasting mechanism for the team only. It isn't something that I advocate anyone else looking at. I also measure through put but again I don't advocate anyone but the team to pay attention.  If you want to know how well my teams are performing, look at the customer satisfaction and our ability to deliver while changing course when needed. 

However, if you must use one of the two options you originally suggested, I say use #2. Your reasons for it being the wrong one are pretty much the reason that I suggest you use it. It encourages the team to stop looking at how many points they can get done and instead focuses them on delivering what the stakeholders are wanting. 

I agree with Daniel. Option #2 for the reasons you think are wrong with it. 

There is a relationship between velocity and capacity. Ultimately, purpose of story point estimating is to assist the team in determining appropriate capacity. If you only look at a Velocity of "Done" work, then you encourage the team to focus on creating smaller stories. There is no value in taking credit for incomplete work. That will allow you to monitor throughput, which if you think about it can reflect the teams feedback loop size, and tightening that up allows the team to alter the Sprint Backlog opportunistically during the Sprint as learning occurs.

Something else to consider, it should also be noted the goal isn't to have 100% completion of each story in the Sprint, as the team commits to the Sprint Goal instead. If you shoot for say 80-90% of capacity to Sprint Goal, really nailing the Sprint Goal accurately, there is an opportunity to begin the next most important work and remove the pressure of having each story be closed by Sprint End. 

I my question I am asking about practical approach advice based on your experience with Scrum teams on which approach/practice works better (or maybe there is another practice I am not covering here at all) with aim to fulfil what Ian was referring to "to help a team get its arms around how much work it can take on in a Sprint and finish to the “Done” standard".

In my experience, using partial credit is simply a way of inflating velocity. Velocity is the measure of story points completed (met the Definition of Done) within a time boxed period (Sprint). Velocity does not and should not account for partial credit because it goes against the original intent of the metric. What happens in Sprint Planning when the velocity is 35? Typically the team forecasts for 35 (plus or minus a bit) story points for the sprint. What if, of that 35, the true velocity (that is the story points that were actually DONE) is really only 20. The team is over-forecasting and the odds of having left-over and undone work at the end of the sprint is very high. 

So practically, is your team consistently taking on work only to have it moved back to the product backlog at the end of the sprint? Are they consistently not completing the items brought into the sprint? I'd bet that it is because of the inflated velocity due to partial credit. Bring that amount back to what it should be, a measurement of the DONE story points in a timebox, I'd be willing to bet the team will stop over-forecasting in Sprint planning. That is what I have seen with teams that I've worked with at least.

Perhaps it's interesting to perform some more detailed analysis on what an estimate means for the likelihood of an item being "Done" within a given sprint.

When the team forecast what will be "Done" in a sprint, presumably there is a mix of items that are 1, 2, 3, 5, 8 points, etc.

Of all the 1 pointers, what proportion are "Done" within the sprint, what proportion are started, and what proportion are not started?

Likewise, perform the same analysis for 2 pointers, 3 pointers, and so on.

Do you spot any patterns?