What is Product Backlog Prioritization and how is it applied within Scrum Projects? We provided a brief description of the Product Owner Role in a previous article where we explained their Responsibilities. One of the responsibilities that we metioned was in regards to the prioritization of the Product Backlog. As the steward of the Product Backlog, the Product Owner is Required to keep the contents safe, complete and Prioritized. Prioritizing the Product Backlog is one of the most important activities in the Scrum Project.

It is a Project Management activity which affects Project Delivery and ultimately Project Success. There is no simple formula on how to Prioritize: there are many Tools and Techniques. Your “Flavour” of Agile and the Practices that your Company favours for Risk, Financial and Stakeholder Management will determine which Tools you use. There are some basic truths to remember about Prioritizing the Backlog.

• This is a ‘Continual Activity’. The Product Owner should Reprioritize the Backlog as often as possible to guarantee Project Success.
• ‘ Work Top-Down’. Start by Prioritizing high level details, such as Epics and Features.
• Work that has currently been assigned for Development (e.g. in a Sprint) is left out from Reprioritization.
• ‘ High-Risk Work has High Priority’. These Features should be tackled early on.
• ‘ Nice to Have’ Items can be treated as Out of Scope when it becomes clear that they will not be finished during this Project.
• ‘ Prioritization’ should be as clinical as possible, and not based on inklings, uncertainty or individual predisposition.
• While the Product Owner (the Voice of the Customer) is accountable for this, it is still a Democratic Process and all Stakeholders should have the capability to provide their opinion, which should be backed by relevant data.
• Each User Story can include extensive information, including Story Boards. The extra details must be kept together with the Story when Prioritization Changes.

Product Backlog Prioritization: Considerations

Let’s take a look at the key aspects that determine Priority for any Work Product in the Backlog.

• ‘ Risk’.
• ‘ Reward’.
• ‘ Need’.
• ‘ Dependencies and Relationships’.

The risks involved within each user story is continuously evaluated. This occurs daily during the Daily Standup meeting.

Handling Project Risk.

Every Agile Development has some daunting Stories in the overall Specification. The Work can be extremely Complex, there is uncertainty about how the Developed Feature will Function, or the entire Project depends on Delivery of this Feature. The temptation to procrastinate on High-Risk Work is obvious. In Projects where this is Done, the likelihood that you will run out of Time and Budget is very high, and you are presenting yet more Risk. A well balanced method to deal with High-Risk Items is to provide them High Priority.

Completing the Risky Work early gives a better view of the Project Timeline and how much must be Completed before funds and time are exhausted. The High Risk Features are often Critical to the Finished Product. Where there was any uncertainty about whether the Solution is Workable, this can be Resolved early in the project. Incorporating Low-Risk Development in a High-Risk Sprint makes it possible for less experienced Scrum Team members to get involved in the Development and get a sense of accomplishment.

Product Backlog Prioritization: Financial Implications.

Everything in the Product has an Estimated Cost connected to it. What will determine Priority is the Return on Investment (ROI) and when it will be Realized. Where there is little or no ROI, this could be a cosmetic Feature which can be given a low Priority. However, before you assign this Story to the bottom of the pile, you have to ensure that there are no Dependencies.

Dependency “Your Back Bone Connected from your Hip Bone”.

If you have a Project Management Background, you will be used to Assigning Dependencies. A seemingly unimportant User Story could have several High Priority Items Dependent on it. Likewise, a High Priority Feature might require the presence of this “Predecessor” for Testing.

Product Backlog Prioritization: Will the Customer be Happy?

All the Factors mentioned above are simple to Identify, Customer Satisfaction is not so easy. It is likewise the most important consideration: if your Customer or Stakeholder does not like what is Delivered, it does not matter that the Software is defect-free and highly effective. This is where the Product Owner’s experience comes in. However, you do not have to rely on guesswork, there are Techniques for Identifying Customer Satisfaction and Expectations.

Kit out your Toolbox.

We are not going into great detail on how to use these Tools and Techniques here. It is also not an exhaustive list – there are other choices out there, and there may be practices already used in your own Company. Do take some time to take a look at some of the approaches below if you are not familiar with them and/or you do not currently have an appropriate Estimation Product that does the Work.

We found these books great for finding out more information on Agile Scrum:

Product Backlog Prioritization: Risk Evaluation.

You most likely have an existing Risk Process that is utilized in your Workplace, in which case, use it. If you do not, we advise ISO 31000. This was an approach that came from Australia and New Zealand, and was called AS/NZS 4360. It is a simple and easy-to-understand Process for Identifying Risk, Defining Mitigations and Assigning a Risk Weighting.

Financial Estimation.

You may currently have some overall Estimation of Return On Investment if your Company Practices Benefits Management. There are a number of Methods of Calculating the Financials you Require. These are:-.

NPV (Net Present Value) – focuses on the Value of money today instead of the Value of Money in the Future.
IRR (Internal Rate of Return) – The time it will take to get the Return.

There are other methods, such a Breakeven Analysis.

Dependencies.

You can construct a Gantt Diagram in your Project Management Software to Track Dependencies in the Product Backlog. It is likewise beneficial to expand into a Network Diagram of the Product – you can Track Completion this way too, and accomplish two objectives with one process.

Effective Outcomes – Customer Expectations.

There is a very helpful Approach for this called the Kano Model. It was Developed in 1984 by Professor Noriaki Kano. It is especially useful today, when Customer Experience has become essential. It allows you to Predict what will make the User Excited or Unhappy, along with what is expected as a matter of Course.

We found these books great for finding out more information on Agile Scrum:

Prepared for Success.

In the long-ago days of RAD (Rapid Application Development), many practitioners thought this was an open invitation to dispense with Documentation and preparation and dive into Coding. Agile is a grandchild of RAD, although considerably more evolved and sophisticated. The User Stories are an essential for understanding the Requirements. In order to take those Stories from paper to a living Product, Planning and Prioritization is essential. A skilled Product Owner will use Changes to the Priorities on an as-needed basis, ensuring that the Critical Components are Delivered, with some sacrifice of non-essential Requirements. This will result in successful Product Delivery and Minimise any rushing to Complete towards the End of the Project. The process of Product Backlog Prioritization can be reviewed as part of the Sprint Retrospective in order to further improve the the process.