Product Backlog: The Key to a Successful Project

As the steward of the Scrum Product Backlog, the Product Owner is Required to keep the contents safe, complete and Prioritized. Focusing On the Product Backlog is one of the most crucial activities in the Agile Project.

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 ensure Project Success.
• ‘Work Top-Down’. Start by Prioritizing high level details, such as Epics and Features.
• Work that has actually already been allocated for the Development Team (e.g. in a Sprint) is omitted from Reprioritization.
• ‘High-Risk Work has High Priority’. These Features must be tackled early on.
• ‘Nice to Have’ Items can be dealt with as Out of Scope when it becomes clear that they will not be completed throughout this Project.
• ‘Prioritization’ ought to be as scientific as possible, and not based upon hunches, uncertainty or individual bias.
• While the Product Owner is Responsible for this, it is still a Democratic Process and all Stakeholders and Scrum Team (Scrum Master, Product Owner and Development Team) should have the capability to offer their opinion, which should be backed by relevant data.
• Each User Story has a lot of Baggage, such as Story Boards. The additional details should be kept together with the Story when Prioritization Changes.

Let’s look at the essential factors that determine Priority for any Work Item in the Backlog.

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

Product Backlog: Handling Project Risk.

Every Agile Development has some frightening Stories in the overall Specification. The Work can be Complex, and there may be unpredictability about how the Developed Feature will Function. Maybe the entire Project depends on the Delivery of this Feature. The temptation to delay work on High-Risk features is obvious. In Projects where this is Done, the possibility that you will run out of Time and Budget is extremely high, and you are introducing yet more Risk. A well balanced technique to handle High-Risk Items is to give then a High Priority. However you should also look to include other Low-Risk but High Priority Stories in the Backlog. These will generally be Features that are visible to the Stakeholders on a screen, and Demonstrate Progress to the Stakeholders.

Getting through the Risky Work early gives a better view of the Project Timeline and how much should be Completed before funds and time are exhausted.The High Risk Features are usually also Critical to the Finished Product. Where there was any uncertainty about whether the Solution is Workable, this can be Resolved. Incorporating Low-Risk Development in a High-Risk Sprint enables less experienced Team members to participate in the Development and get a sense of accomplishment.

Is it Worth the Effort? Financial Implications.

Certainly, everything in the Product has an Estimated Cost attached 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 might be a cosmetic Feature which can be provided a low Priority.

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. A High Priority Feature might need the existence of this “Predecessor” for Testing.

Will the Customer be Happy?

All the Factors pointed out above are easy to Identify, Customer Satisfaction is not so easy. It is likewise the most crucial 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 can be useful. Nevertheless, you do not have to rely on guesswork, there are Techniques for Identifying Customer Satisfaction and Expectations.

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

Kit out your Toolbox.

We are not going into great detail on how to utilize these Tools and Techniques here. It is likewise not an exhaustive list – there are other choices out there, and there will be practices utilized in your own Company. Do take some time to analyze a few of the approaches below if you are not acquainted with them and/or you do not already have an appropriate Estimation Product that does the Work. You will also require a scorecard to get a final weighting.

Risk Evaluation.

You probably have an existing Risk Process that is utilized in your Workplace, in which case, use it. If you do not, we recommend ISO 31000. This was an approach that originated in 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.

Product Backlog: Financial Estimation.

You might already have an Estimation of ROI if your Company Practices Benefits Management. There are a number of Methods of Calculating the Financials you Require,these are:-.

• NPV (Net Present Value) – concentrates 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.

Dependency.

You can construct a Gantt Diagram in your Project Management Software to Track Dependencies in the Backlog. It is also helpful to expand into a Network Diagram of the Product – you can Track Completion in this manner too, and Kill Two Birds With One Stone.

Effective Outcomes – Customer Expectations.

There is a very useful Approach for this called the Kano Model. It was Developed in 1984 by Professor Noriaki Kano, but is particularly valuable today, when Customer Experience is so essential. It enables you to Predict what will make the User Excited or Unhappy, as well as what is anticipated as a matter of Course.

Something that sits in the upper rightmost quadrant is High Priority from the Customer or Stakeholder point of view.

Product Backlog: Get ready for Success.

In the long-ago days of RAD (Rapid Application Development), many professionals thought this was an open invite to dispense with Documentation and preparation and dive into Coding. Wrong. Agile is a grandchild of RAD, although significantly more developed and sophisticated. The User Stories are an important component for understanding Requirements. In order to take those Stories from paper to a living Product, Planning and Prioritization is key. Among the Benefits of utilizing Agile Development is that Changes and adjustments can be applied during the Project and the order of Work can be Changed to accommodate these Changes. 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 lead to successful Product Delivery and Minimise any rushing to Complete towards completion of the Project.