I recently received an email from someone who had taken one of my Scrum courses on Pluralsight. He asked:
- For the next Sprint, how is this unfinished User Story/Documentation task handled and is the User Story re-estimated for its remainder to arrive at Story Points?
- If the User Story is not considered for Sprint 1 Velocity given that it is not complete, and if its considered entirely in the second sprint when complete, this will skew the Velocity. As organizations love to measure Velocity and would like this to be fairly consistent, it does not help. Wouldn’t it help to have the story points prorated for Velocity discussions? If Documentation would have taken 2 % (we can use task estimations in hours to find out the relative contribution), we can consider 98% of the story points for velocity. What do you think?
WHEW
This was my reply to this poor soul who is clearly being beaten down by a manager or someone else who doesn’t understand what this whole velocity thing is all about.
I do not advocate for re-estimating the work. Just leave it on the board and let it finish, taking the Story Points in the next Sprint. It will all come out in the wash. Just try to limit this by learning to plan better to your team’s capacity.Trying to arrive at a consistent velocity is a dysfunction. Take the averages and don’t work about Sprints being consistent. What happens when people go on vacation, become sick, etc.? Velocity is a historical record and lagging indicator. It is a poor predictor as a leading indicator because of the reality of life.I hope this makes sense. In short: Don’t let the process beat you to death. Let it flow and don’t worry so much about perfection 🙂
This pitfall is also avoided when Velocity is defined as a rolling average of the previous N sprints.
Which sacrifices the ability to notice change quickly. You are better off plotting it on a control chat and using Nelson rules to decide when it has changed.
https://en.m.wikipedia.org/wiki/Nelson_rules