What to do if the team cannot finish all the items before the sprint

Hi Dravid,

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.

Jeff,

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

Hi Dravid,

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.

Best regards

Eduardo Hdez

I am assuming that items not completed are re-estimated as work may have commenced on them, unknowns will now be know meaning effort required may have reduced or actually, increased?

I am assuming that items not completed are re-estimated as work may have commenced on them, unknowns will now be know meaning effort required may have reduced or actually, increased?

That's certainly possible. Like many things, Product Backlog Items can, and should, be subject to ongoing inspection and adaptation.

I am assuming that items not completed are re-estimated as work may have commenced on them, unknowns will now be know meaning effort required may have reduced or actually, increased?

I have teams that don't re-estimate when things are carried over.  They find that keeping the original estimate gives them more insight when they start to retrospect on their estimation process.  For example if a team estimates something as a 5 and it ends up taking 1.5 Sprints to complete, there is a discussion on how they mis-estimated. What was uncovered that they didn't expect?  Then going forward that comes into play with their future relative estimation.  They estimate based on what actually happened after they did their original estimate. It has served them very well and their estimations have improved quite a bit. They tried re-estimating and found it to be difficult to compare going forward. Do you estimate based on the combined number since you have re-estimated based on the remaining work or just based on the last estimate used?

Let the team decide what is best.  Yes, the Scrum Guide says that estimates should exist but all but one reference to "estimate" is focused on the Product Backlog.  If a story is carried from one Sprint Backlog to the next Sprint Backlog, does it really need to be estimated? In the end, the team should decide what works best for them.  

If a story is carried from one Sprint Backlog to the next Sprint Backlog, does it really need to be estimated?

My only comment on this approach Daniel (and I think we've discussed this before) is that choosing not to re-estimate items carried from sprint to sprint can reduce transparency into the actual size of the remaining item/work.

But as you also mentioned (and I completely agree), it should be left up to the Scrum Team to determine what works best for them.

@Timothy, you are right.  We have debated this more than once.  I actually prefer the "don't re-estimate" approach. But just as I have had teams not re-estimate, I've had them that will. I have even had teams that will re-estimate during the Sprint instead of waiting for the Sprint boundaries.  All of them have been effective for the individual team. 

I sometimes let my preferences cloud my comments here.  That is why I am always mindful to add the "what ever works best for the team" and "this is my opinion".  I already do some long responses. If I really tried to cover everything I feel/think about each question, I might as well just start a blog site and post links to it.  :) 

Also, would not re-estimating the work skew the velocity of the team within the next Sprint; for example, consider that a piece of work was almost "Done", most of the work was carried out in the last Sprint. It was estimated at 5 points of effort, and the development team estimate there is only 1 point of effort left to complete the work, it moves into the Sprint Backlog and is completed within a day or two of the next Sprint starting, only 1 point of effort was consumed but the value attached to the work is 5. This would over-inflate the team's velocity for that sprint.

Darren, I believe that is where the difference of opinion lies.   

Some prefer to forego re-estimating items that are carried over, in favor of saving the expense of re-estimation and allowing the full amount of points to be "credited" upon completion, which promotes a "velocity = effort" viewpoint.

Others prefer to re-estimate items carried over, in favor of promoting transparency around the actual size of items forecast for the next sprint, and promoting a "velocity = completion" viewpoint.

A couple things to keep in mind:

• Story points only have value from a planning perspective.   Once the sprint starts, the points no longer matter (unless assessing whether to de-scope items to accommodate new sprint backlog items)
• The Scrum Guide is not prescriptive at all regarding this.   Development Teams only need to be able to assess what they can achieve in the upcoming sprint, using whatever tools/data/methods they prefer

Excluding the reasons why... if the team doesn't complete the work planned for the sprint, can this be considered as technical debt?.

yes, incomplete work will go back to the backlog, and more actions will be taken after that, and one of those actions will be to identify when is that pending work will be completed, there is where I think that the concept of technical debt fits on.

For me, technical debt not only represents works to be completed or worked after a delivery ( like issues) it can also represent work pending to complete... thoughts?

What do you think the relationship might be between technical debt and the Definition of Done?

DoD can be reviewed, something is happening that turns into a collection of impediments for the team to complete the work during the sprint planned.. but at the end the work is incomplete... so the team can end up carrying over between sprints technical debt.

I have served Teams who re-size and those that do not. What I can say from my experience and observations is that re-sizing seems to offer an empirical advantage.

Interesting to note that “estimation” and “estimates” are no longer referenced as part of the 2020 guide. This has been replaced with “sizing” and “size”.

Let’s talk about the idea of work carrying over.

A Sprint backlog only really exists in the context of the Sprint in which it was created for. When a Sprint completes, the associated Sprint backlog ought to dissolve and be replaced with a new one that aligns to the next Sprint Goal.

Teams may opt to continue incomplete work from the previous Sprint, but this should not be a given. If we are working empirically, we may have inspected something that causes our priorities to shift (market changes as an example) and although work has started, it may make more sense for it to be shelved to support adapting to the higher priority. 

Some questions that come to mind:

• How is Transparency, Inspection and Adaptation impacted when just carrying work forward without discussion and re-sizing? How do we incorporate what we learned from the last Sprint?
• Why is the sizing (essentially a guess) from the previous Sprint so valuable that it should be locked in and maintained?
• What might be learned from reviewing the updated sizes for a PBI that took more than a Sprint to complete?

I have stated that I don't feel like re-estimating is useful.  However, that is based upon the discussion of re-estimating the remaining work.  If a team wants to change the original estimate of a 5 to a 13 to account for the additional work due to discovery, I can support that.  I can also support marking the current item as "Done" if it meets the Definition of Done and is part of a valuable increment. In those cases I suggest that new tickets be created in the Product Backlog to represent the remaining work and be treated just like any other item.  

I advocate that whatever approach is taken by a team, a discussion should take place at the Retrospective on why this situation occurred.  That conversation can often lead to the decision on how to manage the issue.  This also allows the team to treat each instance independently rather than creating a hard set rule for how it is handled every time. 

In my opinion, estimates are only useful for forecasting how much work the Developers feel they can pull into a Sprint.  But I also advocate that it not be the only measurement tool.  Kanban metrics of throughput, cycle time, and work in progress can be valuable, sometimes more valuable.  Those metrics are based upon the actual work that took place and not a guess made based upon limited knowledge. 

As I've said all along, this is something that each individual Scrum Team should discuss and handle.  I believe empiricism comes into play if every occasion is discussed independent of others and then generalizations made as appropriate.  I do not believe in a stated process on how the situation will be handled unless it is "we will discuss, learn and adapt each time".  

Hi everyone!

1. It's not good to extend a time-box event, so please DON'T.
2. If your team did not deliver a PBI on time (end of a Sprint), as a SM you should understand some points:

When did the team realize that they wouldn't reach the Sprint Goal (or part of it)? Half of the sprint? At the end of the Sprint? Timing in Scrum is very important (read crucial).

What do you do to not waste time (lean thinking)? You inspect with transparency and adapt. How do you do that? Daily Scrum, Burndown chart, other metrics. If the team realizes any impediment or "complication" in Sprint Backlog on time, they can renegotiate with PO what they can delivery at the end of a Sprint without delays. Some teams call that Sprint backlog refinement.

Have a nice day, week, year! Hope you all be healthy.

Hi,

First of all I became happy, that there are other teams and SM which have the same problem as me. I made dashboard on Jira which shows the story status of sprint, remain day of sprint, heat map the status of sprint. in all daily we review the board and dashboard, but non of them did not help to complete at least 90% of sprint tasks. Although in each planning I ask developers to double check the sprint backlog and if they are too much, don't pick them. In the middle of sprint they are free to put the backlog out the sprint. with all of this solution, the problem didn't solve.

in all daily we review the board and dashboard, but non of them did not help to complete at least 90% of sprint tasks

If they are meeting the Sprint Goal and have delivered at least one useful, valuable, and done product Increment, perhaps there's nothing wrong with 90%?

I ask developers to double check the sprint backlog and if they are too much, don't pick them. In the middle of sprint they are free to put the backlog out the sprint. with all of this solution, the problem didn't solve

Perhaps solving the problem directly for the developers has impacted their ability to self-manage in order to come up with their own solution. Why constrain the solution to just yourself and use the wisdom of the team? A Scrum Master can facilitate the conversation, be a mirror to the team, teach about the Sprint Goal, Scrum Values, and having a Done Increment, but should not dictate solutions.

Scrum on

I think the team must be more accurate with estimation of the story points 

If any team do not know their speed exactly; then the sprint may end early or lately

Hi all, quick question. 

I'm new to scrum and looking of ways to improve our companies understanding. I just wondered if anyone could clarify a couple of points.

• If a PBI is not going to be finished by the end of the sprint, am I right in saying we allow the sprint to finish and move that PBI into the next sprint (Should this be the high priority still)
• If the PO & SM is unavailable for the sprint review and retro due to training, should that event be moved to say the Monday, or allow the developers to still hold them with the option to record it? The other option maybe to extend the length of the sprint by a week?

Sorry if these seem like simple issues but I'm stuck between wanting to stick to the scrum framework and events to trying to ensure we get value out of the Review & Retro.

Thanks in advance 

Wayne

• If a PBI is not going to be finished by the end of the sprint, am I right in saying we allow the sprint to finish

The Sprint will end when the timebox for it expires. It's not something within your power to allow or disallow.

• and move that PBI into the next sprint (Should this be the high priority still)

The Product Backlog should give transparency over the work that is believed to remain for the Product. The Developers should re-estimate any unfinished work there accordingly. The Product Owner may -- or may not -- then order it as a priority matter for consideration in the next Sprint Planning event.

• If the PO & SM is unavailable for the sprint review and retro due to training, should that event be moved to say the Monday, or allow the developers to still hold them with the option to record it? The other option maybe to extend the length of the sprint by a week?

The Sprint ends when the clock says. You couldn't extend it even if you wanted to. If it were possible to do so, transparency and accountability would be reduced. The team need to see and understand they have a problem and make the best decision under the circumstances.

What happen when there is no item in Backlog. Does it mean Scum is successful as there is not item in backlog?

What happen when there is no item in Backlog. Does it mean Scum is successful as there is not item in backlog?

An empty backlog suggests that there's no longer any work worth doing. I wouldn't necessarily equate this with success.

From the Scrum Guide

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

If the Product Backlog is empty it would indicate to me that your organization what has been called a "cash cow".  If people are still using the product but you are not investing any money in maintaining, that is a good thing.  If the Product Backlog is empty because the organization has determined it is not worth investing in work on the product, that could also be a good thing. But it could also be a bad thing. 

I, like @Ian, find it hard to equate an empty Product Backlog with success.  If you are referring to a Sprint Backlog, I would have similar views and find that hard to equate to success as well.  An empty backlog simply says that there is no more work to do within the context of the backlog's purpose. 

I know you had a typo in your question but I really think I might use that phrase at some point in the future.  "The backlog is empty, looks like Scum has been successful".   :-) 

tl;dr When do your teams fix the features that have not been developed properly?

Let's say a developer has quite a big task and does the PR close to the end of the sprint. Then either in the review or during the testing, it turns out this is not done properly and the dev needs to fix it before being able to release it. And the sprint is finishing. What do you do in such a situation? Do you treat this simply as an unfinished item of the backlog? 

Then either in the review or during the testing, it turns out this is not done properly and the dev needs to fix it before being able to release it.

In this case, you're saying the backlog item doesn't meet the definition of done, so yes the item should return to the product backlog to be reprioritized. If it's still valuable to do it should return to the sprint backlog in the next sprint planning session. 



Don't fall into the sunk cost fallacy. Just because we've already done some work on it that doesn't mean we have to finish it. The question is still, as always, "what is the most valuable thing to work on next?" and all the usual rules of product ownership and development accountability still apply.