So what’s the big deal with carryover? Lemme tell you about WASTE

So what’s the big deal with carryover? Lemme tell you about WASTE

June 19, 2017 Estimating Lean Product Ownership Productivity Scrum Methodology 1

Talking to a team about carryover at a daily scrum meeting led me into a very uncomfortable confrontation with someone who already didn’t like me. Not sure why but I ascertained it had something to do with the unhealthy relationship between product and technology organizations and the fact that product was pushed by sales to make commitments on behalf of the teams that were essentially never met on time (more on that issue in a later post). So a contentious confrontation – read on…

I was observing a daily scrum meeting and the team was discussing picking up new work toward the end of the sprint. I cautioned them that there were only a few days left and they should be making sure there was nothing they could do to help others get  work completed versus starting new work that would not be finished before the end of the sprint (kind of like this sentence). It was a reminder of WIP and its implications. I suggested starting a spike or picking up a defect or two because testing was a bottleneck on this team (and really all teams that are less than cross functional). The team seemed receptive but the product owner gave me a dirty look. “No output is not an option,” he retorted.


“Well,” I said slowly and as calmly as possible, “Carryover is not an output, and it doesn’t get us closer to our sprint or release outcomes in a potentially non-wasteful way.”

Ha! That silenced him (which in this case was not a good thing). So we both left the daily scrum thinking each other was the enemy because we had our eyes on the same prize but in different ways.

Let us review: we are looking for outcomes over output, that is, achieving the outcome with the least possible output.

Waste in software development is BAD! Mary and Tom Poppendieck say so in Lean Software Development. One type of waste is just that, unfinished carryover work. Why you ask? Well since agile is about flexible scope with a fixed team and budget, we are more free to adjust the scope when something more valuable comes up. In this case, when the timebox finishes, we reprioritize to ensure we’re working on the most valuable scope and we stick with it for the timebox. Should this constantly change? No. Does it? Yes (again, another post). SO if something is not done and we reprioritize, we are stuck with some work that we can’t use. That is waste my friends.

“But Natalie, we can pick it up later!” Sure we can but will we? Sometimes. In the meantime, it will need to be maintained in the branch it is in and when we do integrate later after a lot of changes, it’s going to be a lot harder. Also, there is the effort that is wasted by context switching between things and not finishing them when you’re already focused on it. See smart graph I got from the internet below (Quality Software Management: Systems Thinking):

And what if it is never picked up and reprioritized as important? Then any effort that was put into it is now considered waste. No, it doesn’t mean the code is shit, it just means it won’t be used and that time and effort could have been used on something more important. OR if the unfinished work would have been finished, it could have been implemented and used, even if it did end up being lower priority, at least it was done and usable.

Now I’m sure the latter never happens; something is de-prioritized after it’s been started — please sense my sarcasm as I’m on a flight that was started and not finished and resulted in a huge waste of my time after being diverted, waiting, and finally getting stranded in a city I didn’t anticipate being in. Oh…you wanted a software example? How about those defects that were so important until another one came up and the first was forgotten about until there is a list of 100 that are 1+ years old? Or the HiPPO’s (highest paid person’s opinion) new idea that was brought up and replaced in less than a release/sprint/day? No output is not an option indeed, well not finished != output. And output does not always lead us to the outcomes which are more important. Monitor and eliminate waste and you will hit your outcomes (your true top priority outcomes that are the MOST important) much faster. If your outcomes are changed on the daily that’s another problem.



One Response

  1. […] Natalie Warnert explains why carrying unfinished work over to the next sprint is wasteful. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

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