Closing a Backlog

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active
 

A closed backlog? What? I mean we all know that agile changes.

It moves and the end product isn't always what was envisioned at the start. Right? Well, yeah, sometimes.

At my current engagement we ran into a rare instance though, where we all agreed that the backlog was CLOSED. No more new stories, no more additions, no scope creep. At all. Hell, we even got the executives to agree to close it. Of course this was a unique situation that I wouldn't try to force into most enagements. 

 

We had a team that spent most of last year battling to deliver this specific product. As the year progressed they ran smack dab into every PM's worst nightmare: the job was bigger and badder than expected. Really big and really bad; in fact they couldn't deliver their prodcut at all. So management took their lessons learned and scrapped the old team, giving the work to a new team that had some different ideas how to achieve the goal. I was asked to scrum the new team and ensure product delivery as my highest priority task for the new year. The delivery date was absolutely MUST MAKE. No excuses.

 

Since we were building on the ashes of the old team we were able to make use of their original backlog and artifacts from the Product team. I mean this was great! We already had most all of the initial leg-work done for us. And it was good work, too. No one thought the stories were bad, or the backlog itself, there were just challenges on HOW the thing was done. So we took over their backlog, cleaning things up where it was needed. We re-wrote items where we could and wrote new ones if we had to.

 

Then I made my pitch... 

  1. We have a highly critical delivery date.
  2. We have a backlog that has been gone over by almost the entire company by now.
  3. There were no possible changes that we could see coming down the road.

 

Given all of that I started talking with the executives first: Does it make sense to keep the backlog agile and open and risk moving the date, or should we say that unless there's a major emergency THIS is what we're delivering on THAT date? Which is more valuable to the company? Well, with the frustration of the previous team failing to deliver anything it was a bit of a no-brainer. 

 

Then I started pitching the same thing to the team, the other scrum masters and the PMO. My pitch to them focussed more on removing any and all potential for scope creep from the project, and they all loved the idea.

 

During the kick-off I delivered the news to everyone that the team's business analyst was the ONLY person who would be allowed to add new stories and then only under certain circumstances. I told everyone that we were comitting to delivering THIS specific set of features and no more and that we, as a team, were all going to be responsible for stopping scope creep in its tracks.

 

We're in our third sprint and so far its going well. We've only had one instance where someone tried to create a story without having the BA do it. But the single most valuable thing this has done is to critically focus the team on the message, "We'll deliver THIS set of features, and no more." At least not until after the release date we agreed to. We're already working with several requirements that are beyond our scope and in each case we simply tell everyone, "Yes, we agree that this is a great feature. Hang on to it until we open up our backlog again and we'll bring it in at that time."

 

Now, is this agile? No, not at all. Is it smart business? Yes, I think so. The team thinks so. The company thinks so, too. We'll know this spring! :)

 

 

 

 

 

 

Author Bio:
Lee Allison
Author: Lee AllisonWebsite: http://www.allisonagile.com
Agile Coach
Lee is an experienced Agilist and IT professional who loves the people-centric nature of Agile practices. He and his awesome family live in Austin, TX where they watch the Cowboys, brew beer, laugh and wish the weather weren't so damn hot!