1- the sprint should be extended
2- the sprint ends with done items
3- the sprint should be cancelled
4- the unfinished sprint items should be removed from the sprint backlog
5- start the next sprint with the unfinished items first Saving Changes...
Sort By:
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
The sprint ends. It's important to set time boxes on your iterations, or you'll simply have unmanageable scope creep, and you'll end up scheduling ad hoc reviews with your customers, which will discourage participation.
Be honest. Show what work was completed and what was not.
Unfinished items get moved to the backlog. They might be at the top of the backlog and could be included in the next sprint. Or perhaps priorities have changed and they're not as important, right now. It really depends on what your new sprint goal is, and whether or not those items help contribute to that.
Your team should reflect on the reasons why there were unfinished items at the end of the sprint, and come up with a plan to avoid this in the next sprint. That might mean taking more time to plan your sprint so they understand the amount of work involved, lowering your expected capacity, or mitigating some of the obstacles that slowed them down.
Then they get to start a new iteration and try again. Saving Changes...
Sprint items not completed will go back to the Product Backlog. Depending on the prioritization the items may be candidates for next sprint or later sprints to be pulled by the teams into their sprint backlog.
In the special case that ALL sprint items are not completed, this topic must be on the agenda for the retro and analyse the reasons and to adapt. Possible reason can be that the refinement prior to sprint planning did not really work. Most likely sprint items were too large and/or no shared team understanding about the story content. Saving Changes...
As Wade indicates, if one is using a sprint-based approach (which is not the only way to deliver in an adaptive manner, BTW), then incomplete and not started work items would normally go back on the backlog to fight for survival with all others.
The sprint ends regards of the status of the work items - it may end early should the PO elect to cancel the sprint in the case where sprint goals are unachievable or some other rare "special cause".
Now the one variant to moving specific items back to the backlog would be if sufficient work had been completed on a portion of the work item (i.e. horizontal slicing of a story) such that there was a potentially shippable incremental work item which still meets the DoD and INVEST criteria. In such rare cases, the work item could be split into two smaller work items - one complete, one incomplete going back on the backlog. This usually only happens in the case of mature teams. Immature teams will tend to hit a sprint end date while in the middle of a delivery stage for a work item so nothing for that work item is shippable...
Kiron
...
1 reply by Stéphane Parent
Oct 24, 2019 1:01 PM
Stéphane Parent
...
If you have a shippable partial feature, then the backlog item should have been further decomposed, before or during the iteration.
Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
First, let's first be clear that Agile does not have sprints. There is a distinction b/t Agile and Scrum.
If the committed work is not completed, a couple things can happen; 1) there can be a discussion if a give uncompleted story has value delivery from what was committed, should the story be split to then move the remainder forward with the value portion demoed with the rest, and 2) an incompleted story would move back into the backlog, with a potential to move into the next sprint. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I will assume that you are using some method/framework based on sprints. As @Andrew mentioned sprints is a tool that you can use in Agile, no more than that. First, you have to define in advance what determines the "sprint end". Second, perhaps you will run other spint then you have to take all the stuff from the previous sprint and plan the new ones with all that on hand. To do that you have to have on hands the decision criterias neede to evaluate all the remainded information to start planning the new sprint. Some people think that using agile based methods/framworks is magic. Here comes when people understand that is not. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Oct 23, 2019 7:15 PM
Replying to Kiron Bondale
...
Abdessamad -
As Wade indicates, if one is using a sprint-based approach (which is not the only way to deliver in an adaptive manner, BTW), then incomplete and not started work items would normally go back on the backlog to fight for survival with all others.
The sprint ends regards of the status of the work items - it may end early should the PO elect to cancel the sprint in the case where sprint goals are unachievable or some other rare "special cause".
Now the one variant to moving specific items back to the backlog would be if sufficient work had been completed on a portion of the work item (i.e. horizontal slicing of a story) such that there was a potentially shippable incremental work item which still meets the DoD and INVEST criteria. In such rare cases, the work item could be split into two smaller work items - one complete, one incomplete going back on the backlog. This usually only happens in the case of mature teams. Immature teams will tend to hit a sprint end date while in the middle of a delivery stage for a work item so nothing for that work item is shippable...
Kiron
If you have a shippable partial feature, then the backlog item should have been further decomposed, before or during the iteration. Saving Changes...
