One of the most common questions I hear time and time again, and I bite my tongue every time I hear it: What do we do with stories that are incomplete and end up in Sprint. What do we do with them? Can we split them with “finished?” Let’s say we have a 5-point story. Do we split it into a 3-point and a 2-point story? So, we finish 3 points in one Sprint, then we put 2 points into the next Sprint. That way we show some progress. It concerns me that people feel that they need to do that to show progress.
One of the philosophies I strongly believe when it comes to Agile is: Agile is meant to show you where the problems are. If you cover up by splitting up stories so you can show progress, what that does is an antithesis to what Scrum is trying to bring out.
Let me give you an example:
Let’s say there are three Sprints: 1, 2, and 3. (Watch my YouTube video for a visual of this example: http://bit.ly/2g8GBMQ)
If you finished nothing as you’ve got big stories in Sprint 1, you hit 0 point in velocity. But in the next Sprint, because you got stories that overflow, you hit 20 points. And the next Sprint you get 0 point again. What’s wrong with this picture? You hit 0 point because you have stories that overflow that are incomplete. And scrum is very clear about this: It’s all or nothing.
But people don’t like to see 0. They don’t like that we didn’t deliver anything. So, they have a tendency where they say: Can we split up this Sprint so we can have something where the 0 is? Let’s say 5 points. And then we can move the 15 points of incomplete points up to the next sprint. What that shows is you are creating a delusion that we finished valuable work.
Either a story is complete, or it’s not. When we have a pattern like this where we have 0 points, 20 points, 0 points, in three Sprints, this is meant to indicate an issue.
For example, if it’s 20 points in Sprint 1 and 0 point in Sprint 2, what that shows is either the stories have some dependencies, or they are too big. So, this is meant to help us. It means we should take some action: Maybe we can identify dependencies, or perhaps we can make them smaller up front, so they move on to complete. Rather than splitting up Sprint into two stories, after the fact, which disguises the real problem: Our Stories are either too big, or we did not identify all the issues. This is the main reason we do not split stories purely for the intent of showing progress. We need to address this issue, not just do this to show progress.
Velocity is a measure of the amount of work a team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the points for all fully completed user stories. If you split incomplete stories during a Sprint, and mark them complete to show progress, you create a delusion that you completed valuable work.
So, to go back to our earlier example: If you got velocity in one Sprint and the next Sprint is zero, there’s a reason for this. It could be the story is too big, it could be dependencies, there could be numerous other reasons. And this gives us an opportunity to address it before it becomes a greater bang in the system.
Scrum is meant to help you find issues early, not hide issues by artificially changing your reporting. That’s one of the most common mistakes I see teams make when they’re starting to use Agile. I see them still trying to create this illusion of some progress. We need cultural transparency. We need to be comfortable with that. To do that, to have transparency is essential for us to be able to improve. If we cannot be honest about problems or challenges or constraints, how can we possibly work on anything at all?
So, Project Managers, love scrum.
Velocity tracking is also for risk litigation. Do you want to know the truth or not? If you want to, then it is about finding issues early rather than late. If you find in Sprint 1 that you are hitting 0, and you know the reason, you can do something about it in Sprint 1. If you wait for delivery to find out, that’s way too late.
Agile will help you deliver much better results because it gives you so much more information early on. It tells you all your problems early on, but you need to be comfortable seeing the truth. You need to be comfortable in understanding the issues, invest the time to find out the issues, and support your team to get away from that.
It’s okay if teams start at 0 and hit 20 then hit 0 again. That is fine. Help them get out of that. Assist them by identifying dependencies early. Maybe create smaller stories. Provide better estimates. Or give them more information they need to help them do their job.
That is part of servant-leadership. It’s a new style of management. And we need to do that more efficiently and adhere to the discipline of Agile.
There is a reason Scrum is so clear on stories not being split for the sake of showing progress. Either the story is done, or it’s not. Either you find the value, or you haven’t.
Agile is intended to surface problems with our delivery so we can improve. If we change the reports to make it more palatable, we lose much of the benefits.
I hope this helps you understand the reason we don’t split stories in Sprint after the fact just to show progress.
If you have any questions, please post them in the Comments box below, and I will be sure to answer them.