To DeScope or Not To De-Scope

Questions that prompted this note :

"What happens to our Sprint Backlog and Burndown chart if we have unfinished items at the end of the Sprint?  Do we remove the items so our Burndown can hit zero?"

First of all, let’s establish expectations on when we should know that we have items that are not going to get finished in a Sprint.  While it’s certainly possible that the Team didn’t realize they would not finish all of their committed work until the very end of the Sprint, a more reasonable expectation is that the Team sees this coming ahead of time.  They should be monitoring their progress and their velocity to anticipate not completing everything they originally committed to.  I’m not a big fan of letting the Product Owner and other stakeholders hear for the first time at the Sprint Demo that we didn’t finish all of our commitments.

Back to unfinished work and the Sprint Backlog.  Opinions differ on this, but the general consensus in the Scrum community is that the Team should indeed De-scope after consulting with their Product Owner on what items should be removed.  To do this, the Team would literally remove the unfinished items from the current Sprint Backlog, thereby decreasing the total remaining work left for the Sprint.  (These unfinished items can then be moved to prioritization consideration during the next Sprint Planning meeting.)  The Burndown would then reflect a corresponding dip downward, hopefully now trending us more towards zero.

This method makes perfect sense and portrays a clean picture of reality, and Teams use this method all the time.  The problem is that we lose some information that might be important for the Team’s continued growth.  We lose the graphical representation of the just-as-important reality that we did not meet all of our commitments.

I was working with a team that had been up and running for 5-6 Sprints, and we were reviewing their Burndown history.  In every case the Team hit zero.  Great!  Closer inspection, however, showed that in most cases their Burndown had a sharp dip downward towards the last day of the Sprint.  They had De-scoped work in every Sprint in order to hit zero.  There was a problem here that was not being addressed:  the Team was consistently missing their commitment and there wasn’t much being done to change this.  The Team had come to believe that De-Scoping was the answer to their problems of missed deliveries rather than digging into the issues, finding root causes, and getting better at planning and meeting commitments.

Might it have been more of a noticeable problem if the Team had decided to leave the Burndown in full Scope, showing that they had never met zero?  Possibly, and that’s my point:  like everything in Scrum, artifacts should have a purpose.  Do we need to retain the non-zero Burndown to do a good job of inspecting and adapting, to continually improve?  If the Team could have benefited more from a full Scope Burndown, then that’s what should have been recorded.  We wouldn’t lose track of the missed items, as we could mark them as “incomplete” and copy them to the Product Backlog or the next Sprint Backlog.

I sometimes make a deal with the Team:  if you can show me how you will address the root causes of incomplete items, then I’ll agree to De-Scope.  If you can’t show me that you will indeed address the reasons why items were missed, like at a Review or Retrospective meeting, then let’s not De-scope until we get to that level of assessment.

From classroom training (ranging from 2-hour overview sessions to 2-day Certification Training) to organizational consulting, we can help with all your IT project needs. If you would like to learn more, call us at 954-575-8766, or email us at info@winnowmanagement.com

You linked to Scrum Notes from the Home page.