Problem with unfinished userstories and their SP
Hi,
my team is using SP for estimations.
When we come to the end of the sprint and there are unfinished userstories we use the following approach:
Get the already done SP of the unfinished userstory, add them to the velocity (so SP of finished stories + "done" SP of unfinished stories),
then shift (at the planning) the unfinished userstory to the next sprint but with only the "open" SP.
In my opinion that makes it pretty hard to calculate the "real" velocity. I think the basic idea was "but we already accomplished something of the userstories, so calculate them as well".
Am I right here or are we doing things right? Is there maybe a better way?
I would say: unfinished userstories (and so their SP) don't go into our velocity.
How do you handle SP of unfinised userstories and velocity?
Velocity is the rate at which work is Done, not part Done. It sounds like you've obfuscated this measure and so inevitably there will be difficulties.
The situation is not helped by eroding the Sprint boundary and rolling unfinished work over into the next Sprint. Unfinished work should be re-estimated on the Product Backlog, which must tell the truth at all times about the amount of work which remains to be Done. The Sprint Review is a formal opportunity to do so.
Any unfinished work may or may not then be planned into the next Sprint. The Product Owner, as well as the Developers, must be franchised in this Sprint Planning decision. Bear in mind that by that point -- in a complex and uncertain world demanding agile practice -- the PO may have bigger fish to fry.
In my opinion, using Story Points to calculate velocity is your first mistake. Story Points are estimates. Estimates are guesses made based upon the information you have at the time the estimate is made. Once you start work, those estimates are no longer applicable because you are gaining new information.
Then add to the equation your "done" and "start" estimates and the practice of rolling work over to the next Sprint leads me to believe that you are just calculating some random number that has no meaning at all. Let's say your Developers estimate an item to be 8 Story Points but that item is not completed in the Sprint. How does someone decide how many of those 8 points were done? Does the "start" points only include the left over points are can the be points added/taken away?
As @Ian said, velocity is the speed at which work is Done. But when you calculate that based upon guesses, you aren't measuring how much work is done. You are measuring how many imaginary points have been completed. Since every estimate is different, you really have nothing that is measurable. It would be like having two soccer teams estimate how many points they are going to score against an opponent to determine the winner of the game.
If you want to calculate 'the "real" velocity' I suggest you look into using flow metrics like cycle time and throughput. They are based upon actual durations and work efforts. They will provide you a much better understanding of your work, especially given the practice of rolling work from sprint to sprint.
Hello Michael,
Try this for deriving Velocity: Only consider DONE stories as being complete. If a story is partially complete, it is not DONE. So then it is only DONE stories that go towards Velocity. And it is Velocity that is then used to help plan the next sprint. Sticking to that pattern will simplify the process and the team's average Velocity will become apparent overtime, w/o all the juggling & acrobatics.
As for unfinished stories: they are not assumed to be included in the next sprint, but should be evaluated for applicability. The SP value would not change as it still represents the original work of the story as a whole. However, if the scope of the story changes then the SP would need to be re-evaluated.
Hope that is helpful,
k