Product Backlog Anti-Patterns

After the Product Backlog: How Big is Too Big post, I got to thinking of anti-patterns you might observe in how your team manages the Product Backlog. This is by no means a comprehensive list.

I warn you, it’s late and I’m tired…this is going to get weird.

The Decentralized Backlog

This can happen when there is no Product Owner or when there is a Product Owner who doesn’t have a good system for tracking his/her thoughts. Things are jotted down on post-it notes (love those!), thoughts are hastily emailed and flow charts created for deep storage on a shared drive…somewhere. These artifacts live in many places, none of which is terribly accessible to the Development Team or maybe even the Product Owner. Product vision is murky and communication is difficult.

This is cocktail of ingredients that will produce a great deal of waste for the Scrum Team. If there is no, single source for these requirements, any number of wasteful communications become likely.

The Backlog Carved into Stone Tablets

We can sometimes mistake pride in our work for insecurity.”Me, just now

Picture the Product Owner who has just dotted the last “I” after painstakingly creating and arranging all 85 user stories in the perfect order. The dev team didn’t want to have that 5 hour refinement meeting, but according to the PO’s tally, they were way under their 10% refinement time threshold this month-long sprint. The Scrum Master may have objected had she been there, but she took a personal day to engage in serious meditation and calming exercises. All of the work could be summed at any point in time, and the total is 83; that’s a prime number!!!

Things look so perfect, nobody is allowed to edit them without the PO’s permission. Seriously guys, NO TOUCHY! In fact, let’s remove our stakeholders from our Sprint Review; they’ll just mess up the plan…which we must follow. Guys? Where did everyone go? Hey, what’s that sound? (distant waterfall getting closer).

On the surface, this Product Owner’s behavior might strike some as being the act of a person immensely proud of the work he has done. Rather, he acts as an artist who is afraid to destroy his work. A colleague of mine once told me about an art class he had taken, wherein he was to paint something, then white wash the canvas, then paint something else! Alternately, he could sculpt something, bake it, then smash it! The point of this exercise was to force the artist to keep creating and to resist the urge to dwell on past expression without feeling the urge to grow.

You must believe your success is the result of hard work, not luck or chance.

If it is the result of luck or chance, who knows if you will be able to recreate it. If it is the result of hard work however, it is imminently possible to recreate it.

The Bad Room Mate Backlog

We all had that sibling, room mate, significant other, etc who just gets on our nerves. They leave things in constant disarray, unwashed, untidy, and in general make like harder for the rest of us living in this room. We pay rent here too Mark!

This backlog is littered with confusing descriptions, inconsistent estimation, truisms for value statements, and is as ordered as a pile of dirty laundry. The dev team switches between fibonacci story points and T-shirt sizing without telling the PO and the PO spends most of his day arranging his favorite PBI descriptions into haiku:

As a Ghostbuster,

I need to cross the 4 streams

To trap Stay Puft Man

Though the backlog is all in one place, its condition leaves much to be desired. The Product Owner grows to hate living with the backlog which is constant disarray and the Development Team grows to loath the Product Owner who is always nagging about cleaning things up around here.

Final Thought

Keep your Product Backlog in one place and make sure it can be easily understood.

Keep your Product Backlog tidy, but resist the urge to do work on it before the last responsible moment.


Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.