Getting DEEP with your Backlog Part 4

Prioritization should NOT be stressful

This is the last of our discussions to help product owners manage their backlogs better.  We have covered making a backlog detailed appropriately, estimated, and emergent, this week I want to talk about making the backlog prioritized.

The management consultant Peter Drucker said, “First things first.  Last things never.”  What this means is you do what is important and then ignore the other things.  Since becoming a scrum master, I have lived by that mantra and I think it should also be a helpful guide for product owners.  In my experience, I have seen backlogs filled with hundreds of stories of "nice to have" features.  Many of these stories are never worked on and the backlog gets larger and larger creating a sense of futility on the part of the development team and the product owner.

I am also personally surprised by how many people in leadership roles who can’t prioritize.  For example, I asked a person to pick one of two options.  They were so paralyzed by fear and uncertainty that they instinctively said, “I need to ask my manager.”  When I pressed them to make a choice, they said “…can’t we do both? They are both important.”  The reality is that both choices are not as important.  They both need to get completed but objectively they cannot be done at the same time so which of the two choices should we do first.  This creates spasms of doubt from some people.

What I suggest to some product owners is make a list.  Then they number the items in the list based on priority. No two items can have the same value.  If you can’t decide the value of two priorities because they are similar, flip a coin and give the winner a higher priority.  If they are that similar, then the time spent fretting over which is more important is going to cut into the time you could have spent getting work done.  Get the work done; it is easier than explaining why you didn’t get the project done on time or budget.

A good product owner needs to understand what it takes to get a software product into production and what the business needs in order to make it successful.  They also need to make hard choices and set the order in which the work gets done.  They also need to say which work can be ignored.  If a story has been lingering in the backlog for three years and no one has worked on it then it needs to be dropped.  If it was not important three years ago then it certainly will not be missed today.

Your back log can be organized in numerous ways but the most important is by priority.  Do the important things first and provide business value right away.  Then you can focus on the Vice President's pet project after the sales figures improve.

So there you have it, Roman Picher’s DEEP model of managing your backlog.  The backlog should be detailed appropriately, estimated, emergent and prioritized.  It was fun writing this series and hope you got some value from it.

Until next time.