Should we move unfinished User Stories forward to the next sprint?
- Jun 17, 2022
- 1 min read
Updated: May 15, 2023
Unfinished User Stories should not be demonstrated during the Sprint Review. The unfinished User Stories should go back to the product backlog, be re-estimated, and considered for the next Sprint. Re-estimating the user stories ensures that the future work is true to the point estimate. The work performed during the current sprint is “lost” as far as the worked points. Following this process will avoid assuming that every Sprint will have rollover stories and that the stories will remain a priority from Sprint to Sprint.
I appreciate the clear guidance: keeping unfinished user stories out of the Sprint Review helps teams avoid “false progress” and reframe work around a credible estimate. Sending them back to the product backlog, re-estimating, and then considering them for the next sprint creates a healthier feedback loop. That said, I’d add that the team should preserve learnings from the partial work so the next estimation isn’t starting from scratch. Unblock Website
I appreciate the clarity here: treating unfinished User Stories as “not demonstrated” at the Sprint Review and pushing them back to the product backlog keeps accountability and prevents misleading progress. The point about re-estimating is especially important—otherwise we accidentally lock in outdated assumptions from the last sprint. With web proxy online, I’m reminded how visibility and transparency matter; similarly, good estimation keeps the next sprint’s work aligned with reality.
Disagree. Re-estimating would not allow you to get better at estimating. Automatically putting it on the backlog might incentivize developers to run out the clock on stories they hate. Would rather have the team focus on getting the story over the finish line and meeting the sprint commitment.
Unfinished user stories might go back to the pbl only if the po still deems them valuable.