Incomplete SBI -- Accounting for Velocity

There's no such thing as "9 points of completed work". Work is either completed and made available in an increment, or it isn't. The value of completed work can be measured a number of ways...but it is very, very unlikely to be in points.

Points are a means for a Development Team to estimate how much work can be taken on in a Sprint. By extension they may also show the work that is thought to remain in the Product Backlog, if that backlog is fully sized. That's it. They have no value as any sort of currency, nor do they proxy for value.

In the example you give, the size of the product backlog will presumably be reduced by 9 points, assuming no additional work has been added and all other estimates in the backlog remain constant. They cannot contribute to a velocity measure since there has been no corresponding throughput or delivery of value.

Ian, thanks for the response.Yes,I guess I shouldn't have used the word "completed" when referring to work effort that went towards that incomplete item. If I understand your comment, when the velocity of the team is considered for that Sprint, the effort represented by the reduction in the item's estimate from 12 to 3 is lost. If the other items that were included in the done Increment represent 30 points (ie, the team had originally planned 42 points), the team's velocity will appear to be 30. Yet, it seems to me that the team is capable of accomplishing about 39 points in a Sprint and that is a better number to be used (or for averaging in) for future planning than 30. Without doing so, it seems that empericism (sp?) is lost.

Am I missing a significant concept? Thanks!

> Yet, it seems to me that the team is capable of accomplishing about
> 39 points in a Sprint and that is a better number to be used (or for
> averaging in) for future planning than 30

That's the thing though, points are never accomplished. Incremental deliveries of value are accomplished.

> Without doing so, it seems that empericism (sp?) is lost.

The evidence you actually have is that the team delivered value which was estimated at 30 points. No other value was provided. Any additional work that was performed will have consequences for the amount that is thought to remain, hence the size of the Product Backlog can be expected to reduce accordingly.

This might be something I just have to accept rather than have it make sense to me :)

Had the team chosen a 9 point item rather than the 12, they would had a velocity of 39, rather than 30. Or, if that re-estimated item is put back into the next Sprint along with 36 other points, they are likely to complete it. In that case, their average velocity will be captured as (30 + 39) / 2 = 34.5, whereas if you were to look at the total estimated points they achieved over the two Sprints (as a whole), they completed 78 (average of 39). As a PO, working with the DT at the next Sprint Planning (or even planning the longer-term release), which yardstick would you prefer to use to guide the forecast to a realistic goal to maximize value -- the 34.5 or the 39? I realize these numbers aren't that far apart, but imagine the same thing with a much larger gap.

Of course, my traditional PM training includes a lot of "Earned Value" study, so that can be tainting my view, but when an item expected to "cost" 100 hours of effort is 50% completed, you get credit for 50 hours of value (whether it took 30 hours or 200 to get there).

I'm here to learn!

> Had the team chosen a 9 point item rather than the 12, they would had
> a velocity of 39, rather than 30

Correct...but they didn't. That's empiricism.

Bear in mind that it is entirely up to the team how they estimate how much work they can take on in a Sprint. If their velocity was 30, and they knew they had 9 points of capacity which was spent doing undelivered work, then there is nothing to stop them from taking that into account in the future. It is simply the case that, in terms of evidence, a deliverable increment sized at 30 points was most recently provided.

Thanks, Ian. I understand that the DT determines what they can take, so it makes sense that the (perhaps temporarily) wasted effort doesn't necessarily affect their future planning. For the PO creating the Release Burn-down chart, that will be affected if using the velocity numbers this way, perhaps artificially projecting a later release (or fewer PBIs).

I appreciate the discussion.

Hi Craig,

Average Velocity is usually done over the last 3 sprints. As the team might be new and has a few teething problems, doing it earlier would not reflect a reasonable number.

There are a few options for an incomplete user story and its points:

- The team only gets credit for the completed work. So if it's completed in the following sprint 2, all 12 points got to sprint 2 and 0 in sprint 1.

- If the work will be completed in a future sprint (eg. Sprint 4) then split the user story (in 9 and 3 points) and create an additional one for the 3 pointer, with the uncompleted part. Mark the 9 pointer as completed in sprint 1 and complete the 3 pointer in sprint 4.

Was the story too big and should have been split earlier maybe? Was something else preventing the completion?

The idea in Scrum is to deliver Value items in the sprints. Value as in Value to the Customer. So it's Value driven development and not Velocity Driven Development. Revisiting some items in the backlog and see if they can be split up to avoid future situations like this would be one of the first things you could do.

- If the work will be completed in a future sprint (eg. Sprint 4) then split the user story (in 9 and 3 points) and create an additional one for the 3 pointer, with the uncompleted part. Mark the 9 pointer as completed in sprint 1 and complete the 3 pointer in sprint 4.

Please don't choose this option, Craig. Any effort around re-estimation in order to clarify or get credit for what was "done" in a sprint is a very wasteful practice. Don't do it.

Nicko has s correct approach wit his first option, though. When the 12-point story is completed, all 12 points will get credited to that sprint. It all balances out.

The team should use their velocity as a measuring "guide" for forecasting future work. They should not have a hard and fast rule around meeting or exceeding their velocity. The team should always rely on their best judgement when forecasting sprint work. If a story was carried over, and the team knows that most of the story has been completed, ensure that they take that into consideration when making their forecast.

There is another option - do not use story points. Instead, work on creating smaller stories that take on average 1-3 days to deliver; then just count the number of DONE stories in each sprint - this is your velocity.
The variation in the size of the stories will average out over a few sprints. Your ability to forecast the amount of work a team can take into a Sprint will also improve due to the relative simplicity of the process...

Nicko/Timothy -- yes, I am partially comfortable with Nicko's first option -- that salvages the team's *average* velocity as the long view captures all the points (assuming that the re-forecast item is eventually re-introduced into a Sprint and completed). It still distorts the pattern of the team's productivity (referring to ability to accomplish work, irrespective of when/if it made it to "Done"). I recognize that might be a different metric (not defined in/by Scrum, but permitted within its framework), but there is usefulness in understanding if the team is becoming more efficient -- working together better, using tools to their advantage, etc, apart from what comes to completion in the Sprint in which it was first introduced.

Boris, yes, I agree -- the smaller the items are, the less distortion there is when the situation arises. Thanks!

Boris' suggestion is good esp. when starting out and it avoids your 9-3 issue. It's basically doing my option 1 beforehand and not afterwards.

Not using story points as such might give some confusion for the team members, but de-chunking stories to a level of 1 to 3 points is a good way to go.

Try to avoid focusing on Velocity only. A valuable item should be delivered. That could be an item with only a few story points for that sprint. It's not an indication that the team hasn't done any work as they have worked on an item that just can not be delivered in this sprint but will be delivered in a later one.