When Is It Time to Redo Your Backlog?

31 December 2013


It's not ideal, but sometimes it's reality: You look at your backlog and it's a mess. You don't know who's doing what and what is happening when; it's a bit like Abbott and Costello. What should you do about it -- clean it up or start over?

I recently observed this problem, and this is what we decided to do.

Signs that you need to redo your backlog

In our situation, the backlog was not transparent and was definitely not easy to understand. Not a single epic had been completed, therefore delivering no value. User stories were poorly written and most did not provide any acceptance criteria. Only some stories were estimated, and it was impossible to produce a release burn-down.

As an immature Agile organization, it was good to see that we recognized this and, rather than ignore the signs, we did something about it. What did we do?

How to redo your backlog

We could have cleaned up the current backlog, but there were some fundamental principles missing. For example, a lot of the epics were written as functions, not as features or components -- or anything, really. Even if a team did finish an epic, it still would not deliver value. The effort to reorganize the existing epics outweighed the benefits, so we started again from scratch. It was a chance to start fresh.

We began by holding a two-day workshop with all the product owners. We first laid down the principles of a well-groomed backlog (see Mike Cohn’s article on DEEP). I also pointed out that the product owners should be accountable, not responsible, for the backlog and that the quality of the input into a sprint would reflect team output.

Then we split into teams and wrote a few epics each. We came back and reviewed each other's epics as a group (inspect and adapt). We did this twice to get an understanding of what good epics look like and make sure that they were independent and provided value. Even at this early stage, our backlog was emerging and already looked better than the old one.

We created enough epics to get individual product owners and teams going. Everyone owns the backlog, so it was up to the teams to help break down the epics into user stories. This was the focus over the next couple of weeks.

At the end of the workshop, we committed to each other that the backlog needed to remain transparent and easy to understand. We decided that, going forward, we would hold each other accountable for keeping it DEEP.

Conclusion

If your backlog is a mess, don't be scared to acknowledge that it is so; be brave and redo it. Having a transparent, easy-to-understand backlog is much better than trying to navigate and micromanage a mess.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (2 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.