I recently received the following question, asking about how to account for the story points of stories that are started in one sprint but completed in a later sprint. There are some interesting things to consider here about the user stories, the scrum team, the product owner and the scrum master. I suspect the answer to this will take multiple articles, much like our recent series on splitting big user stories into smaller user stories. Let’s begin!
Let’s say you’re doing weekly sprints and this is Week 1. You believe you can accomplish 20 story points in this week, and you have stories A, B, C, and D – each worth 5 points – scheduled for this sprint. So you plan to accomplish:
A – 5
B – 5
C – 5
D – 5
You do about 80% of A, 60% of B, 80% of C, and 100% of D. If you could get partial credit, it would be:
A – 4
B – 3
C – 4
D – 5
But since you can’t count partial credit, your actual count of the points completed is as follows:
A – 0
B – 0
C – 0
D – 5
And your velocity for Week 1 is 5.
Then in Week 2 you again plan to accomplish 20 story points. We’ve done 11/15 of the work on stories A, B, and C, so there should be only 4 story points left of work to do on these. We can accommodate 16 more story points, which are represented by the next stories, E and F at 8 points each. So our accounting could look like this:
A – 1
B – 2
C – 1
E – 8
F – 8
This would give the appropriate estimate for Week 2 but would miss credit for the full story value of A-C. On the other hand, if you keep the full story value of A-C, our plan for Week 2 would look like this:
A – 5
B – 5
C – 5
E – 8
F – 8
And then it looks like you are planning 31 points for a sprint that can only accommodate 20. It seems that somehow you need to keep track separately of how much work you estimate is really left on A-C to properly plan Week 2. So how do you properly account for partially complete stories across sprint boundaries? Is there some way you annotate that on the cards for partially completed stories?
First Level Answer
In this installment, I’ll try to answer the direct question that I was asked: “How do you properly account for partially complete stories across sprint boundaries?” Let’s start by defining some key terms: user story, story point, and velocity.
A user story is a business deliverable. When a user story is done, there is demonstrably more value present. A user story is something that some of our stakeholders would understand and be interested in.
Not all user stories are the same size, in terms of the amount of work that will be required to deliver them. Story points are a relative scale that scrum teams use to estimate how much work each user story will require. A story that has an estimate of 2 story points is believed to be about twice as much work as a one-point story. Story points are estimates; they are not measurements. Since they are estimates, they are made before the work starts and are not adjusted after the work has been completed.
Velocity measures the rate at which the team is delivering stories. That word ‘deliver’ is very important. The business wants to know when it will get the deliverables (user stories) from the team. Velocity is a metric that helps us predict that. If all stories were the same size, in terms of implementation effort, velocity would simply be the average number of stories the team delivers per sprint. Since stories are not all the same size, velocity is the average number of story points worth of stories that the team delivers each sprint. While estimates are guesses, velocity is a measured value. The unit of measurement just happens to be estimated story points.
Velocity is not a measure of how much work the team is doing. Velocity is not a measurement of how long it took to deliver the stories. Velocity is not a measure of how hard the team is working. And velocity is not a measure of the team’s productivity.
OK, we’ve defined some terms and concepts. Let’s get on to answering the question that was asked. If the team finished one story in sprint one, and its estimate was 5 points, then the team demonstrates that one story in their sprint review and records their velocity as 5 story points.
So the now the team moves on to planning sprint two. The question the team needs to answer is which stories do they have full confidence they will deliver by the end of this sprint. Story point estimates and velocity are tools that can help the team make better commitments about how many stories they will deliver. The team should consider more than just the points and velocity, however. They need to look at the specifics of each story the product owner is asking for and decide, as a team, if they have full confidence that they will be able to deliver that story this sprint. You say that the team believes they can complete stories A, B, C, E and F in sprint 2. That’s fine. If the whole team believes that they will deliver those five stories, then they may commit to them.
Let’s assume that the team manages to complete all five stories in sprint two. They have now completed 6 stories in two sprints. The total of all the story points estimated for those stories would be 5 + 5 + 5 + 5 + 8 + 8 = 36 story points. Thus, the team’s velocity is:
36 points / 2 sprints = 18 points per sprint.
If someone asked what the team’s velocity is, we’d say “18 points per sprint.”
This measured velocity can help the team plan for the future. For example, committing to deliver 20 points worth of stories in a sprint is probably too much for the team right now. The team’s velocity also helps the product owner with release planning. They can expect that, on average, the team will deliver 18 points per sprint and so they can forecast how many stories the team will be able to deliver over the next several sprints. After each sprint, the team will recalculate its velocity and the product owner can update the projections.
In summary, count the story points for a user story in the sprint in which the story is delivered. Do not count partial points for partially completed stories. If the story was started in one sprint and finished in another, that’s fine. Velocity measures delivery, not work, so account for the delivery when it actually happens.
That’s concludes my first-level answer to this question. There is actually a lot more to explore. Stay tuned, as I plan to post a deeper analysis soon. Until then, happy scrumming!