Daryl Katz Riethof
In Scrum, the backlog of tasks is ordered by the Product Owner from highest to lowest business value - not merely prioritized - so that the team knows what the most valuable items are. This helps to prevent Product Owners/Project Managers from being able to say two or more Product Backlog Items (PBIs) are the “same priority.” And this makes sense for the most part. However there are times when this information is not enough.
I am the Product Owner of a team, and we are coming to the last few sprints for a project (re-styling an already existing website, with some new features being added for this phase), and there is still a significant amount of high business value tickets in the backlog. The team is feeling anxious and overwhelmed by the pure amount of tickets they see sitting there, regardless if they are aware that the list is refined. In order to assuage this anxiety, and also help make a plan to allow us to hit the deadline, I decided to make use of the priority field in JIRA.
To keep things simple, I decided to use three priorities - High, Medium and Low. I started by ranking the backlog items on my own:
- High priority PBIs are a must-have for this website to go live. These are items that I know as the client representative are non-negotiable.
- Medium priority is for items that I think the client would want if we could get to them, but would probably be ok without for this phase of the project.
- Low priority is for items that would not likely be missed by the client, the end-user, or our team.
The PBIs included tasks as well as bugs. While Scrum states that bugs don’t belong in the backlog, that is where my team found it most useful to keep them.
I then exported this list to be able to see all PBIs prioritized at a glance (PMs love Excel!), and reviewed it with my team to get their sense on whether my priorities matched their expectations. It was especially helpful on PBIs labeled as Technical Debt, since the developers have a better sense of which of these items are absolutely required for launch. It was also invaluable to ensure that our QA analyst had a say in what bugs were not critical for launch, and to ensure any critical bugs were not overlooked in my prioritizing.
To my delight, a) the team didn’t change many of my priorities, and b) while this exercise obviously did not decrease the amount of work we still have to do, it did quell some of the anxiety around the seemingly endless backlog.
And to those Agile purists out there, I am still refining the backlog in the “correct” way. But this exercise was valuable in helping align everyone’s priorities, and share with the team a bird’s-eye view of where we are at, and how far we have to go.
