How should a scrum team count the story points for user stories (product backlog items) that are started in one sprint but completed in a later sprint? This question comes up frequently and has surprisingly deep implications. It also has a simple answer. Let’s dive into an example that a client sent me.
Let’s say we’re doing weekly sprints and this is sprint 1. In sprint planning, the scrum team commits to four user stories: A, B, C, and D. Each user story has an estimate of five story points. At the end of the sprint, the team has completed story D. The have done about 80% of A, 60% of B, 80% of C. If we give the team ‘partial credit’, the points completed would be:
A – 4
B – 3
C – 4
D – 5
Since there isn’t partial credit, the actual count of the points completed is:
A – 0
B – 0
C – 0
D – 5
The scrum team’s velocity for sprint 1 is 5.
In sprint 2, the team believes they can complete 20 points worth of backlog items. They believe they’ve done 11/15 of the work on stories A, B, and C, so there should be only four story points worth of work left to do on these. They take on 16 more story points worth of product backlog items, which are represented by the stories E and F at 8 points each. So the accounting for the sprint commitment could look like this:
A – 1
B – 2
C – 1
E – 8
F – 8
This would give the appropriate estimate for sprint 2 but would miss counting the full story points for A, B, and C. On the other hand, if they keep the full points of A, B, and C, the plan for sprint 2 would look like this:
A – 5
B – 5
C – 5
E – 8
F – 8
Now it looks like they are planning 31 points for a sprint that can only accommodate 20. How should we account for partially complete stories across sprint boundaries?
First Level Answer
In this installment, I’ll try to answer the direct question 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.
User Story / Product Backlog Item
A user story (product backlog item) 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 required to deliver them. Story points are a relative scale that scrum teams use to estimate how much work each user story will require. Estimates might be created using the Easy Estimation With Story Points technique. A story with 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 tool for predicting delivery. 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 the team delivers each sprint. While estimates are guesses, velocity is a measured value
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. Velocity is not a measure of the team’s productivity. And management should not use velocity as a metric.
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 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. You can read the next level answer in the article: A Scrum Master’s Perspective on Story Point Accounting.