Question:
Our scrum team doesn’t always finish all of the user stories we’ve brought into the sprint. At sprint review, we let our stakeholders know which user stories are not completed, and then we roll them into the next sprint. Is this the best way to handle user story spill-over from one sprint to another?
Answer:
I recommend that anything not completed at the end of a sprint be returned to the product backlog. This allows the product owner to take a fresh look at those items and decide how important they are now. Just because something seemed important last sprint, doesn’t mean that it is still a top priority. The PO should carefully consider if those items are still worthy of being on the top of the backlog. If they are high priority, then the PO can introduce them again in sprint planning, where the developers get to decide if they have capacity and confidence to commit to completing the item(s) in the coming sprint. Again, just because something seemed doable last sprint doesn’t mean that it still seems doable now. Sometimes the team will commit to an item because it looks easy, only to discover that it is much more work than anticipated. It may be that they now believe it will take much longer to complete the item, and that it should be broken down into smaller items that can be considered sprint ready.
You might also be interested in this article on what to do with story point estimates and how to calculate velocity when a user story isn’t fully completed in a sprint. Feel free to drop in on our free online open office hours to dive deeper into this topic with our amazing scrum community.
Best of luck,