What to do if the team cannot finish all the items before the sprint
What to do if the team is unable to finish the items before the sprint, is the sprint extended ?
no, the Sprint ends when the timebox expires. Unfinished Sprint Backlog Items go back to the Product Backlog and can be addressed in the following Sprint.
That's better than extending the Sprint because
- the team can get better in estimating
- of reduced complexity due to the consistency of the Scrum Events (no need to reschedule meetings etc.)
- maybe a Sprint Backlog Item turns out to be big enough for 10 Sprints - so by extending the Sprint you wouldn't work agile any more
what is the recommendation from scrum, continue the sprint as the dev understand what they are capable within the given time frame and move the remaining to product back log
Suppose you extended the Sprint, how much can you afford to extend it ?
You can extend but then you lose much of the accountability and opportunity for improvement. if you consistently modify sprint times you lose the ability to write stories effectively, manage the backlog, estimate effort and lose personal accountability. The timebox exists for accountability and to help each role learn and develop. if sprint lengths vary it becomes very difficult to measure velocity. it's better to reintroduce unfinished items to the backlog and give the team another chance to select their work. it's a good learning experience.
The beauty of Scrum is the focus on people and their behavior. The team selects the work instead of being assigned the work. This is huge! Plan driven methodologies failed due to a lack of buy-in from team members. The team knows upfront the deadline. If they don't hit their milestones use it to revisit how the work was selected and estimated. Communicate and train! If you don't, missed sprint deadlines might become commonplace.
The Scrum Guide is pretty clear on this: you don't extend sprints. At the end of a sprint, if there is incomplete work: "All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog." This does not have to mean that the sprint was unsuccessful, as per the Scrum Guide: "If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner." and also during a sprint: "Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned."
Having to reschedule Sprint Review meetings alone would keep me from extending a sprint time-box as it may be difficult to get the appropriate stakeholders on the new meeting (this may not be a problem for extremely small companies but for a company of any size, necessary stakeholders may have a variety of commitments to other meetings/projects/issues etc.).
The only time I would change the sprint time-box would be if it turned out to not match the needs of the product. For example, if the scrum team chose a one month sprint time-box, and this did not allow enhancements/features into the product marketplace fast enough to keep up with competing products/companies, there is probably good reason to change the time-box. But this should be a one-time decision and not something that varies from sprint-to-sprint.
That means anything extension is out of topic sir
What do you do when there is a roadblock found during the sprint and there is no way to complete the work? For example, the data needed is not in any database due to a gap in business process. Do you close the user story? Also, do you burn down the remaining unused hours because the user story cannot be done at all?
I just ran into this. There is one main Product Backlog item that remains partially done, probably 75%. This is my first sprint and I am a team of two (at this point) so I have some flexibility to break the rules (this time) and thus, I am simply carrying on with the coding as we speak (well after I finish this comment :) ). Reason I am carrying on is this is a fairly complicated feature that required a decent refactor of heavily used code and to stop now and come back to it later would cost a lot of time to refresh the memory on the wiring of the whole thing. For me, this is time I can't waste on formality of re-adding it back to the PB and coming back to it a couple of days later. But I have learned a few lessons here, such as a) honing our estimation accuracy in the future and also b) that sometimes it might make sense to grab a higher sprint point item like this way earlier in the sprint rather than grabbing the low hanging fruit first, then hitting the higher sprint points items last. In the future with a larger team I'd probably keep the scrum structure (and not break the rules) and punt it to sprint+1 but make it first on the list and go back to it right after the review and retrospective.
A couple key points I would like to raise around your post:
- First, it is an excellent sign that you have looked at an undesirable result in a sprint (unfinished item), and identified several options to hopefully lessen the likelihood of it recurring in the future. This reflects not only an empirical approach to work (inspect/adapt), but also reflects a commitment to Continuous Improvement, which is a critical attribute to anyone wishing to work Agile-ly
- Second, it is important to state that in Scrum, there simply isn't the concept of % complete. Items are either "Done", or they are "Not Done". Perhaps a bit Yoda-ish, but it is still a key feature of Scrum
Your question is not easy to answer, since there are many factors that you would have to consider to make your decision, in fact, according to the book, you should finish the sprint, but if you have a new release scheduled or it is an extremely important product, you should validate with your team, if they consider it possible to obtain it in a couple of days, it would be convenient to wait to give a product of value to your clients. We should remember that beyond the purism of the method, the most important thing is delivering value to the customer.