Sometimes Scrum teams start working on new user stories without officially closing an existing/previous user story that is still in progress. This can leave multiple stories open, and at the end of the sprint the team rushes to close all of them.
What are the problems teams might face if stories are kept open till the end of the sprint?
Cannot claim the story is complete
Lots of pressure on the team to close all stories at the end of the sprint
Last-minute risk of no deliverables if stories aren't closed
Uncertainties aren't known to the ScrumMaster unless they're discussed in daily stand-ups
How do we ensure that stories are burned down the way they should be, before new stories are picked up?
Use of a WIP limit
Introduce a WIP (work in progress) limit, a Kanban practice, to limit the in-progress user stories. Split the in-progress column into "Under Development" and "Under Verification" columns, with an appropriate WIP limit for both. By doing this, the "in-progress" column is used more effectively and precisely. If either of these two columns shows stories exceeding the WIP limit, stop working on current activities and get involved in closing these stories. Update the Scrum board (whatever visual one you use, as well as any computerized tool version), which will highlight these columns. Here is the sample of one such updated Scrum board in JIRA:
Sample of a Scrum board with a WIP limit for the split In-Progress column
Use of a visual sprint burn-down chart
The visual burn-down chart is an indicator that shows the number of story points worth of effort remaining on a given day when the chart is plotted for remaining story points of effort versus the number of days in the sprint (the burn-down chart can also be drawn for hours remaining versus number of days). By looking at the visual burn-down chart, one can understand the health of user stories on a daily basis and how they are being addressed during the sprint. It also indicates the impediments that have arisen, showing how the actual burn-down graph varies significantly from the ideal burn-down graph.
Following is a visual burn-down chart that shows how, ideally
, the stories should be addressed and closed. Any significant deviation in the actual burn-down chart compared to the ideal draws the attention of the ScrumMaster and the Scrum team.
Sample visual burn-down chart
We have been using Agile for a few years, and the intent of this article is to share some of the best practices we have found to get the concentration of the ScrumMaster, if user stories are not closed by the teams in the way they were supposed to be. Restricting the WIP limit and having the sprint burn-down chart both indicate the actual way the stories are burned during the sprint compared to the expectation. Thus they can grab the attention of the ScrumMaster, who will look for any impediments.
This "Finish to Start" method is, we have found, the best approach to address multiple opened user stories during a sprint.