There is an art to dealing with undone work in Scrum. Many questions that pop up in Scrum Teams with undone work relate to estimation:

  • “Should we re-estimate undone work in Scrum?” 
  • “If we do, how do we get credit for the work done previously? 
  • “If we don’t how do we account for new insights in the size/effort of the work to be done?”

These are valid questions with fierce advocates for either approach. I myself have done both in the past. To help you answer these questions, let’s look at four different ways to approach undone work estimation in Scrum. Then look at some underlying principles of Scrum, and evaluate what is the most helpful approach for you. As long as we agree that IF you use estimation and want do use Scrum in an effective way, the ONLY smart thing to do with undone work is to re-estimate the work remaining.

Four ways to deal with estimation and undone work in Scrum

In all below approaches we will work with StoryPoint estimation, because this is most widely used. The ideas discussed will work just the same for T-shirt sizes or other types of estimation. The example work item was originally estimated to be 8 StoryPoints and the team did not get all the work needed done within the Sprint. It doesn’t really matter why. It may have been an honest error, or the team forgot about some essential but significant amount of work, or more work emerged through learning during the Sprint that could not have been foreseen at an earlier time.

Approach 1: Keeping the first estimate

Keeping the first estimate seems a logical choice at first. So, let’s say we estimated an item using StoryPoints, and as a team we thought it would be 8 points. If we want to get better at estimating, we want the estimates to be comparable AND have the feeling that they match the total effort we put in a certain piece of functionality, then it follows that we should notadjust them. 

We are however adjusting something else. In this case, there will be some mental adjusting of the estimated effort we associate with the number 8. And over time we will settle on a more or less stable effort associated with ‘8’ and the other numbers we use.

We also disregard new insights into the estimated effort needed until the item is ‘Done’, and must remember to account for work already done as well as work remaining when considering the item’s ordering on the Product Backlog, as well as when crafting a Sprint Plan. In which case we might just as well throw Scrum out of the window, since we clearly don’t care about Transparency, which is supposed to be a key pillar of Scrum’s Empirical Proces Control.

Our historical data is also a bit less transparent since our estimates are as volatile as the work we are doing, meaning if we have a large amount of new work discovered, the estimates ‘size’ changes a lot as well. To prevent this, teams tend to add padding/buffers and stay on the safe side by inflating estimates even more. Thus making them even less transparent & useful. It’s safe to assume I am not a fan of this approach.

Approach 2: re-estimating the work remaining

Not only do we adjust the original estimate, re-estimating in this case is a NEW estimate of the work remaining. This is the logical ‘other’ choice when dealing with undone work. Originally, we thought the effort to deliver this Product Backlog Item (PBI) was 8 points. For whatever reason, we did not get it delivered within the Sprint. The team investigates the work remaining to deliver the sought after value, and re-estimates the PBI to be 5 points. Note that the new estimate is often lower, like in this example, but doesn’t have to be! 

To be able to re-evaluate the effort of completing this PBI against other options on the Product Backlog we should weigh the remaining effort only, to avoid the Sunk Cost Fallacy. To maximise value the only thing that counts is money we are still willing to spend to potentially create a certain amount of expected value. It may very well be that another Product Backlog item is estimated to take less effort and deliver more value than the item that has been already worked on. To provide the Product Owner with the best information possible to base their decisions off, we need to keep a focus on work remaining and potential value delivered per PBI.

In this case, Sprint Planning is made easier because the StoryPoints of each item represent estimated effort remaining to ‘Done’ and as such help the Scrum Team planning based on past performance and expected capacity. 

The past velocity only takes in account work ‘Done’ which helps the team focus on planning an amount that they can actually get Done in a Sprint, as well as drive a preference for making the work as small as possible. Since in that case the hazard of not completing a large amount of work is lower, and has less impact on the velocity and forecast.

A final benefit is that in re-estimating the work remaining, the team has essential opportunities to discover and learn more about the work and the sought value of the PBI, increasing the chance of discovering & delivering an optimal solution (minimum effort, maximum value).

Approach 3: re-estimating to accommodate work done plus work remaining

Why not re-estimate the total work item, work already done and work remaining? Now that we have the two most suggested approaches out of the way, let’s look at this combination. Best of both worlds? So the item was 8 points. Let’s say we have discussed the work remaining as a team to be 5 points. Now the total should be 13 points. What happens next?

The Product Owner has to do some mental accounting to keep in mind that there’s actually just 5 points of estimated effort remaining. There are two possible unwanted ways this could go. The chance is very high that the Product Owner will not take this into account, and consider the full amount of points when weighing this PBI against other options on the Product Backlog. Thus placing it lower than it should be (considering estimated investment needed vs potential value expected). On the other end of the spectrum: the Product Owner is influenced by the Sunk Cost Fallacy. Since we already spent 8 points on this PBI, it would be a shame to not get any ROI in terms of output and potential value. We must build it, no matter the cost, even though there may be other options that have a higher potential ROI. 

Sprint Planning will be harder too, since the team will have to do some mental accounting during Sprint Planning (if this item is included). This item is 13 points, but we already ‘burned through’ 8 points, meaning this Sprint we only need 5 points. So we can add more! This seems the same as ‘Approach 2’, but the team has to keep a mental count different from the actual numbers, costing some mental overhead. Meaning that they have less mental energy to spend on creating the best Sprint Plan possible. Another way this can go down is that the team simply disregards that the new points include previously spent effort, to stay on the safe side. Meaning the team plans a lot less than it could deliver. In a positive case, this pans out ok, since the team can always pull more work if they have ‘Done’ all work planned before the Sprint ends.

Velocity is as volatile as in the first approach, but balances out over sprints, since work ‘not done’ in a Sprint is re-accounted for in subsequent Sprints. IF the Product Owner chooses to still want the PBI delivered! If the Product Owner decides an item that was already worked on is now less valuable in terms of ROI, it doesn’t matter.

Approach 4: splitting the item to account for work done (partial ‘done’ work delivered) and re-estimating the part of the work remaining seperately

Splitting the PBI after the fact into a ‘work done’ and ‘work left’ part should not be done when this results in unreleasable work associated with the ‘work done’ PBI. The only work that should be considered ‘Done’ is releasable work that conforms to the teams’ Definition of Done. If you disregard this essential part of Scrum, you’re even doing worse than in Approach one and I suggest you stop pretending to work in Professional, empirical manner. you obviously don’t care about Business responsibility, so please don’t associate yourself with Scrum.

This can be a Professional approach though. Let’s say the Development Team has discovered new ways of delivering value, that can be split into separate, potentially valuable PBI’s. In this case it is acceptable in my book to: 1. deliver the minimal functionality in the Sprint by getting that ‘Done’ and 2. create new PBI’s for the work split off during the Sprint (work remaining, work ‘undone’, work not started yet). I even expect that the Development Team already does this before the Sprint ends, as part of Inspecting & adapting the Sprint Backlog. For example when we discover during Sprint that a PBI that had just one broad customer group mentioned, actually has specific implementations for specific customer groups. Splitting this item for each new specific customer group is fine. The resulting PBI’s not ‘Done’ in the Sprint are then subject to re-estimation if needed after the Sprint ends, or when the Scrum Team decides to put them on the Product Backlog instead of keeping them in Sprint upon splitting.

What is estimation for in Scrum?

So after these examples, let’s look at the underlying principles and ideas on estimation in Scrum.

  1. Starting from the definition of Scrum: since we are working on complex adaptive problems, we should keep in mind that we cannot accurately forecast the amount of work needed to deliver a potential piece of value (outcome) or even functionality (output). 
  2. Product Backlog Items should have an estimate. The Development Team is responsible for all estimates. (Side note: the estimate can be _null_ or ‘1’ for each item, which is how you can work with #noEstimates within the Scrum framework.) 

Given these two building blocks, we can see what estimation is for in Scrum:

  1. Guiding decision making: whether we think the potential value of the item is worth the estimated effort (expected ROI), relative to other items on the backlog;
  2. Planning: forecasting of what a team expects to deliver in a Sprint (get ‘Done’) by contrasting to previously ‘Done’ work per Sprint (velocity); 
  3. Planning: forecasting likely completion dates of (a set of) Backlog items; 
  4. If you can think of more, please tell me in the comments below!

So estimates are NOT intended to evaluate achievements, or attach rewards. Remember, in Scrum we want to minimise effort and maximize value. (This is what Jeff’s book ‘doing twice the work in half the time’ is about.) So it is a bad idea to use practices in a way that focus on output, velocity and utilisation. 

Another thing we learn from the Scrum Guide regarding estimates is under the segment on Sprint Cancellation, which imho also applies to regular ‘undone’ work.

If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated. 

The approach that best matches the principles and values of Scrum: Re-estimation of work remaining

The above is why I urge you all: if you use estimation ALWAYS re-estimate remaining work. You are planning to fail if you don’t take into account new insights that impact delivery effort.

AFAIK there is never a valid need to ‘keep’ original estimates. We don’t need to account for the past. Forecasting is future oriented. If you want to account for the past, track work time spent per item or something similar. Scrum has no guiding principles on this, so it really is up to you and your context whether you need to do this. I cannot think of a valid reason right now, though.

Share your stories and questions on estimation and undone work below

When starting this article, I set out to just write a quick brain dump on this topic. It became this article, and I have decided to publish it as you have read it now. Just like Product Development, this article can and should probably be iterated on based on feedback. Please let me know what you find valuable and what you think is confusing or dead wrong. Any feedback is welcome. I love to learn together.

I am also very curious to your experiences around estimating of undone work. Have you used any of the described approaches? Maybe an alternative approach that I missed? Why? How did that work for you? What was its impact on forecasting, planning, Backlog Management and ultimately Transparency and Value delivery? Let me know!

PS This content has also been published as a linkedin pulse article:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.