How can we manage the issues that were planned to be done at one sprint, but at the end, it didn't, and has to be done in another. Do I change the Milestone? Do I create a new issue on the new Milestone? Or something else? The biggest problem is knowing when the issue did not fit in the sprint and had to move to the next, without appearing in the reports as if it had been made in Milestone planned.
2
-
2There is no such thing as a "milestone" in Scrum. Can you explain what you mean?– nvoigtCommented Jul 22, 2019 at 18:24
-
Are you using JIRA or some other piece of software that you're trying to conform your process to? What you're describing isn't "Scrum," but handling unfinished work is certainly a universal problem.– Todd A. Jacobs ♦Commented Jul 23, 2019 at 17:04
Add a comment
|
2 Answers
How can we manage the issues that were planned to be done at one sprint, but at the end, it didn't, and has to be done in another.
In Scrum, at the end of the Sprint, the common recommendation is that unfinished work is returned to the Product Backlog where it is prioritized. Unfortunately, the only context for this in the Scrum Guide is in the context of a cancelled Sprint.
In practice, there are two options. The work can be "rolled over" into the next Sprint or the work can be put onto the Product Backlog for reprioritization. How this is done is up to the Product Owner and Development Team, but there are risks and trade-offs. At the end of the day, the Development Team needs to be able to accept the Sprint Backlog and Sprint Goals based on their capacity.
Do I change the Milestone? Do I create a new issue on the new Milestone? Or something else? The biggest problem is knowing when the issue did not fit in the sprint and had to move to the next, without appearing in the reports as if it had been made in Milestone planned.
This depends on your tool. What tool are you using?
This also depends on what you mean by "milestone" and if the work is still on target for a given milestone.
answered Jul 22, 2019 at 17:24
From what you've described here's what I'm hearing:
- You have a number of issues that during sprint planning were included in the effort for that sprint.
- You have a number of issues that, due to severity, were interjected after sprint planning was completed. They are extra effort for that sprint.
- Regardless of if they were planned for or added because of severity, they are included in the current sprint's effort.
Here's a couple of ways this could go, but the end result is the same.
You have a User Story with issues/bugs/tasks under it. Various work items have been completed, but at the end of your sprint this particular issue wasn't started. Move the User Story to the next iteration. (Depending on the interface you're using, it's very likely you'll just tag it as "carryover" and change the iteration path to the next one.)
You have a single Issue, completely detached from another work item (user story) and your sprint ends without it being started. Move the Issue to the next iteration.
The assumption in all of the above is that the Issue had been included in the sprint. As it was included, it gets moved to the next iteration if not completed.
If this is just a random Issue someone would like to get done and ISN'T included in the sprint, it should be put in the backlog so when you're doing the next sprint planning it can get added at that point.
