Prioritising the Product Backlog for Testers

The Product Backlog is a list that tells the team what need to be done within the project. It breaks down the Product Vision into manageable increments called Product Backlog Items (PBIs), and each PBI would briefly describe what needs to be done. User story formats are commonly used by Agile teams to describe requirements from the point of view of the user.

Even though everything in the Product Backlog has a purpose, all of them are not necessarily or immediately essential. In order for the project to have a better chance at getting a return on investment (ROI), they need to give their users positive experiences at the earliest opportunity possible, especially if the product is new and just breaking into the market. This is why it’s important for the team to prioritise the Product Backlog: to deliver the highest-value features to the users first.

Because part of Agile development involves continuous delivery, ensuring quality in the product is all the more important and puts testers in the forefront. And for testers to be great, they need to be able to help prioritise work effectively as well. Which are the features should be tested first? Which are the urgent bugs that should be addressed in the next deployment? This article will describe some factors in prioritising the Product Backlog as well as some techniques that can be used in prioritisation.

Value

There are several kinds of value, The Agile team must first be aligned with what “value” is to them before deciding which PBIs are “high-value”. To list some, there’s: business value, commercial value, market value, efficiency value, customer value, and future value. According to the Scrum guide, value will depend on the context as well as the organisation where the product development is taking place.

The simplest way for scoping PBIs would be to ask and collaborate with the Product Owner and the rest of the development team: could we achieve the desired benefits without this feature? If the answer is yes, then that user story or bug could be de-prioritised for another release.

Risks and uncertainties

A risk is any situation that involves possible exposure to danger, and linked with risk is also uncertainty. The less the project knows about a situation or technology, the more uncertain they will be about it. And the more uncertain the project is, the riskier development would be. Therefore, risks and uncertainties affect the success of the project, as well.

It could be more strategic for Agile teams to get the riskiest items out of the way, first. If it turns out to fail earlier on in the project, they can still maneuver within the project timeline to assess and improve. Conducting risk analysis would be largely beneficial for the project. Testers can help the Product Owner by determining what the product risks are for a certain feature, if it does not meet the expected quality.

Dependencies

There will always be dependencies within any project. And when it comes to Product Backlog management, it restricts the prioritisation of PBIs, since it will be matter precedence. For example, development of Feature B could not push through until Feature A is completed, while Feature C is dependent on making a certain tool work.

Dependencies could delay the development of features, even those deemed to be highly valuable. This can be mitigated partly by breaking down features and user stories into more manageable work items. Going back to an earlier example, breaking down Feature C into smaller user stories that will tackle parts of the new tool is more manageable than attacking Feature C altogether.

<– Continue Reading –>

Our Book Recommendations

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