Velocity calculations

Question

What is the best way to stop (closed) withdrawn tickets being shown in the Velocity calculations, would that be a change to the filter or to remove the done resolution from the status?

One way is that the Withdrawn tickets are resized to 0 points when they are withdrawn. Removing them from the board would show scope reduction and hides them in a way that could be unhelpful but setting to 0 reflects the reality of there being no work done but that the task is now done so no work still needed.

How do other teams handle this?

Roy Chapman_ysf2ww · Answer

Thank you.

Andy Hurley_geieth · Answer

That depends on the reasons for cancelling/withdrawing. There are many reasons why a team may want to withdraw a ticket and not all of them mean that no work will ever be required by any team. It's messy and does not neatly fall into agile ways of working so a blanket answer is not always the best approach. That said if a team is regularly withdrawing a proportion of their tickets each sprint (pulling other stories off the backlog to compensate) then their velocity would be seriously skewed if the points for those withdrawn stories were included. Then when they have a sprint where stories are not withdrawn it would seem like a drop in velocity. If these measures are being used to observe a teams performance then we need to seriously consider these edge cases.

Nic Brough -Adaptavist- · Answer

Cancelled/won't do does not need to be treated any differently to any other item that turns out to require less effort than was originally estimated.    If you estimate an issue at 4, but only really end up doing about 2 units of work on it, then how do you handle that?  Why is there any need to treat "estimate 4, did 0 units of work" differently?  You don't change the estimates on issues that do lead to work, so why change them on ones that only require someone to read the item and say "it doesn't need any work"?

Most Scrum teams that take an item into a sprint that turns out to need no work simply mark it done during the sprint.  No need to change scope, same as items that require less work than estimated.