The Best and Easiest Way To Prioritize Your Backlog

The Problem

One of the responsibilities of the Product Owner on a Scrum team is to make sure that the best value is delivered for the development resources spent. This determination drives the prioritization of the backlog and rarely is it done in a vacuum, that almost always there are business stakeholders providing the input that the Product Owner has to take into account when determining priorities. It is further complicated when there is a team of Product Owners that have to come to an agreement, and even worse if there is no clearly define Chief Product Owner.

Keep in mind time spent prioritizing and re-prioritizing your backlog adds no value to the product. It is waste and it the words of Taiichi Ohno, waste comes out of profit.

How Bad It Can Be

Over the years I have seen or been aware of various companies struggling with how to prioritize the work to be done by Scrum teams. Imagine a dozen mid to high-level managers flying to one office and spending the better part of a week going over a backlog containing several hundred items. Not only is the very expensive to the company in salary and travel, but there is also the opportunity cost when these people could be doing something else. This is also contrary to the spirit of Agile because things will probably change within a couple of sprints anyway.

Additionally whatever convention is used to indicate priority will quickly breakdown. Some examples are everything was give a ranking of 1-10 with 10 being the highest. However there were too many 10’s, so what do you do? You make some 11 of course. Another try was to rank things as High, Medium & Low. Since everyone knew no low’s would ever get done most things were a high. Again too many items are a H (high) so next go with H1, H2 & H3. Still far too many items were raked H1 to have any meaning.

A Solution

Something I have found that works is to not try and rank by importance but rather to do an order ranking. What should the team do now, next and then after that. You only need to know 3 things that are the top items at this point in time. The current item is what the team is working on and the stories are fully groomed and the UX work has been done. The item that is, to use a sports analogy, “on deck” UX can be working on and the 3rd item the Product Owner can be working on requirements gathering story writing & refinement. Of course, this cannot be a hard and fast rule as some things have a longer lead time than others.

The key is I don’t need to know today the priority of things that I and the scrum team will not be working on in the near future. I just need an ordered list of the next 3-5 items the team will work on. The Product Owner can review with the business stakeholders every sprint to add an item to the list of near future things to work on and make sure the list has not changed.

A Time To Lock-In

Try very hard to not interrupt work on an item once it has been started on by the development team and if possible also the items that the UX work has been done. My rule has always been once an item is in a sprint we finish it. There will be times that there are extenuating circumstances, but that should be the exception and not the rule.

Exceptions

This article is really talking about feature level items, not bugs or other minor fixes. This is something that will take most of the team most of a sprint or maybe two. I always try to have some small tasks that are important ready to go so when a team gets the sprint goal done they have some filler tasks to finish out the sprint. This is a way you can get bugs fixed or address technical debt. The key is they have to be very small items that you as Product Owner include based on your own judgment.

Why It Works

Rather than having hours worth of meetings to give everything a priority, just give the business stakeholders a homework assignment to go off and pick the next three things for the team to work on. You avoid all the talk and debate about is this a 9 or a 10 (we will make it a 9.5) and just have to pick what the business wants the team to do in the next couple of sprints. Trust me I have saved so much time since I went to this method.

The Daily Stand-Up – You Are Doing It Wrong

What Everyone Is Doing

Most Scrum Teams that I know of are really missing the purpose of the daily stand-up.  It is treated as a status meeting that is used to provide some form of a status report to management usually via the scrum-master.  Afterall if management does not get a status report how will they know people are working.  The format is something like “This is what I did yesterday, This is what I plan to do today and I do not have any impediments”.  Further, if there are any impediments the daily stand-up is used to convey these to the Product Owner and Scrum-Master

What It Should Be

According to the Scrum Guide, the purpose of the daily stand-up is for the development team to plan how to accomplish the sprint goal.  In fact attendance by the Product Owner and Scrum Master is not required.  Therefore this should be a 15 minute, time-boxed, planning session on how to best go about getting the items that the team committed to completed by the end of the sprint.

An impediment is really only something that cannot be resolved within the team.  If a team member is struggling with any part of what they are working on they should ask for help from other team members.  The team working together to advance toward a goal is inherent in the phrase Scrum Team.  If you do not know where it came from, look up some videos online about rugby teams and their scrum (or scrummage) and you will get an understanding of why this name was selected and how it stresses that the team should function as a team.

A true impediment should be raised with the Product Owner and/or Scrum Master as soon as the impediment is realized.  Do not wait for the next daily stand-up.

How To Fix The Stand-Up

There are two paths to take.  First of all, if other parts of the organization are demanding status reports then the Product Owner needs to find a way to provide that status.  Keep in mind much of “status reports” are legacy business process left over from before Scrum was implemented.  Look for ways to move the rest of the organization into the Scrum/Agile mindset.  Stop asking for a status report as part of the stand-up and start asking about plans for success.

Second, try having the Product Owner and Scrum Master NOT attend the daily stand-up for a week