Agile Antipattern: Everything is priority 1

I was just working on some Powerpoint slides for our Agile Product Management Boot Camp coming up on March 9 and 10 and I realized I should post a blog entry about the point the slides are making.  Actually, I’m trying to make two points with the slides.  The first point is we tend to work in organizations where the phrase “everything is priority 1” is common.  The second point is my personal distaste for using the phrase “prioritized product backlog.”  I’ll cover each of these points separately.I’ll start with the “everything is priority #1” problem, since that is the title of this blog entry.  Let’s be very clear THIS CANNOT BE ALLOWED!!!  There are many blog posts on the web such as the ones here and here.  I like what the first of those links says about how to explain why everything can’t be priority 1 – we can’t build it all at once!  I usually approach this with product managers/product owners/stakeholders by asking them what they want if they can only get one thing.  They quickly say one thing is useless they need it all.  To which I reply, I know, but I want to make sure we have the most important item built first so we can learn from it and make changes to other items based on what we learn.  I’d like to rank all of the items 1 to whatever, with no ties, so we can always be working on the next most important item and be able to learn from it as well as all the other items which were more important.  This way we will make sure the most important items are in the release and meet expectations.

Which leads into my second point about the phrase “prioritized product backlog.”  If you simply say the words, nearly everyone in the software industry will say  they already do that.  Why are they saying this when a casual observer can tell it isn’t true?  It is because we have overloaded the word prioritization.  Most software people think having a list of 100 items which has the top 97 as priority 1, the next 3 as priority 2 and no priority 3 items is a prioritized backlog.  Sorry folks, but that is a useless list.  We really need a RANKED backlog, where the rankings go from 1-N and there are no ties.  Then we use the list by making sure we work on the next item in the ranking, not just work on some random thing which seems interesting.

We simply have to keep these two issues in mind when we are dealing with the product backlog or we will not be successful.

So, what do the two slides look like?  Here they are:

This is the first post in the “Agile Antipattern” category.  I anticipate having a few more over time.

Until next time, let me know what you think so together we can be working toward Making Agile a Reality™.