When we talk about prioritization, we are fundamentally talking about prioritizing the backlog, as this is the single source of truth when it comes to the product. We also know that it is the Product Owner who is accountable for prioritization. But the Product Owner is not alone in this activity. In fact, for backlog prioritization to be a success, it must incorporate the views, experience, vision of every stakeholder, from the executive committee’s vision and strategy , to the customers and users desires and needs, to the views and feedback of the Scrum team. No other topic shows the skills and abilities of a good Product Owner more that their ability to successfully prioritize the product backlog.
Each member of these groups will have views on what, why and how the product needs to evolve. This is where having a vision, a strategy and a roadmap at enterprise and product level will truly benefit. They add a wall around scope and the future direction, rather than allowing a free for all. A good Product Owner will never satisfy all their needs and wishes, but understanding scope, and all points of view, and prioritizing using empiricism and transparency at the core, are the signs of a great Product Owner . And we know that the role of the Product Owner is to deliver the maximum value from the product. A fundamental way that they achieve this, is by prioritizing all the work that the Scrum team plan to undertake, by choosing the highest value items first. I want to add one important point here. Value does not just mean business value or customer value alone.
Many Scrum experts refers to 4 headings to consider when ordering our PB:
- Value – we are chiefly talking business and customer value here
- Risk – Tackling high risk items early can greatly reduce uncertainty. Failing early in the process is far safer than waiting until the end to realise a certain direction is not going to happen!
- Dependencies – A simple example here would be a product backlog item that needs to be completed before our team, or another team, can start their work. This item will need to be considered a priority and ordered accordingly
- Releasability– The frequency and stability of releases will impact our prioritization in many ways. A simple example could be in choosing a lower priority item in the next release above a higher priority if we cannot guarantee the safety of the following release if the item is date sensitive
Without going into more detail on each, I think that these are great considerations when focusing on the order because at their core, they are all elements of value. I will add a few more. I might bump up the priority of an item if it had the ability to increase the learning we can attain from its time in the customers hands. Also, there can be items where changes in the relative cost of the feature will occur over time. A simple example could be releasing an item that would add value in the lead up to Christmas but less so after!
Can you think up a few more? Note that value criteria are product / situation specific so what is good for your product, might not work for another.
So, let’s assume that we have a Product Backlog and that the Product Owner has defined a roadmap for the coming period. Let’s also assume that we have a process for understanding the Value of each item in the product backlog. Our next step is to prioritize. The Scrum guide includes it under the umbrella of “backlog refinement”.The Scrum guide does not actually use the term prioritization, but refers continuously to “Ordering” the backlog. And as with many topics in the guide, it does not go into any great depth on the WHAT or the HOW to achieve this objective. Remember, Scrum is a framework and therefore not prescriptive on processes to use to achieve your goals!
So, why do we need to prioritize the backlog?
Some reasons are pretty self explanatory. Firstly, the Scrum team needs a list, they can not do everything at once. If we are already determining the Value (and size of course!), of each item in the product backlog, it is not a great leap to make the move to ordering the list with the highest value first? Added to this, the fact is that the schedule and releases are usually moving around, so having a prioritized list means that if we move a release forward, we will still have the most important items covered.
There will be times when you have fixed scope and some might ask why you would need to prioritize around value if all PBI items are going to be delivered anyway. I can think of many ways to answer this one. But two of the more interesting reasons would be in delivering the highest value items early, to gain the maximum possible value as early as possible. Secondly, the fact that getting the highest value items out early will also mean we get the maximum amount of time for customer feedback!
In many ways, release planning is a subset of prioritization . Firstly, we prioritize the backlog and then we use that prioritized list to plan which of these items will fit into the upcoming releases.
It is worth noting that items further down the list, that have not been included in these releases do not need the same level of scrutiny, unless they start to move up in priority.
Product backlog refinement should be an ongoing activity for the Scrum team and deriving value, estimation and ultimately the prioritization of the backlog are all fundamental and necessary activities. But when we reach the point of starting our sprint, and we get into the room to begin our Sprint Planning, we often realise that turning a prioritized Product Backlog into a sprint backlog, is not as simple as picking the top “X” number of items and just getting down to work. When reality sets in, we find that life (and prioritization ) are not as simple as they sound. The team, ie the Scrum MAster, the Product Owner and the development team need to reach a balance between delivering the highest priorities, against a pragmatic view of all the challenges and hurdles at that moment. During the sprint and especially during Sprint Planning, there must be an element of latitude given to the team to allow them to be successful.
I often say that the Product Owner decides WHAT and the Development team decide HOW. But the Product Owner must listen to the development team during the sprint and be flexible with the WHAT.
Let’s take a simple example, imagine our current priority list is set. So we pick backlog item one, item two, three and four for the sprint. But the development team know that they cannot deliver all of item 4 in that time, and want to pick the next item on the list. The PO will need to be comfortable with many levels of flexibility while remaining true to the vision and their role in delivering value. It’s true that their beautifully crafted prioritized Product Backlog will need to be flexible when it hits the realities of real life. In many ways, this is just another part of the whole area of prioritization
And let me say it again, prioritization is all about maximising value and the Product Owner’s primary purpose is to….. I think you know the answer.
FYI: My next blogs will be on User Stories and on understanding Waterfall. Keep an eye out for them!