Cómo priorizar el backlog en Metodologías Ágiles

As a <role> I want <functionality> to achieve <goal> .

However, once the expected behavior of the system has been described in a set of UserStories (called a backlog), there is a problem to be solved: in what order will each of them be implemented, that is, where to start.

There are different factors and dimensions to consider

• Time
• Effort
• Functional Value
• Stakeholders’ opinions,
• Development team opinion
• Market Value, and surely several more.

From these, different techniques have emerged to prioritize the UserStories of the backlog .

The following describes some of the most commonly used techniques [1,2]. To facilitate comparison, a small example of a backlog is introduced. The backlog will then be prioritized according to the vision of each technique. The example consists of an e-commerce application, with the following UserStories:

US-01. As a registered user, I would like to place items in the shopping cart to complete my order.

US-02. As a business owner, I want people to be able to browse the site without registering to facilitate its visibility.

US-03. As the owner of the business, I want only registered users to be able to make purchases to achieve loyalty.

US-04. As the CFO, I want credit card payments to be secure to prevent fraud.

US-05. As a registered user, I would like to check out my cart to complete my order.

US-06. As a marketing manager, I want to make it easy and intuitive to add products to the cart so that users find the page attractive.

US-07. As a marketing manager, I want users to be able to search so they can find the products they want.

Business Value&StoryPoints Technique

This technique proposes prioritizing UserStories based on factors such as the effort and opinion of the ProductOwner, the client and the development team, or even combining them. The Business Value is a numerical value assigned to each UserStory (US) where the higher the value, the greater the value for the client.

So one way to prioritize the backlog would be to use the US Business Value. However, doing so in an “isolated” way can cause problems.

One of them is that the client often gets carried away by superfluous details and this can lead to leaving aside really important functionality.

Another problem is that the effort required to implement each US is not considered. The latter can be solved with StoryPoints , which are numerical values ​​entered by the development team estimating the effort it will take to develop each US. Then, a smart way to prioritize the backlog is by using the Business Value/StoryPoints ratio . That is, the easiest to implement that is of greatest interest to the user. To illustrate this technique, assume the following values ​​for the US in the example:

Given these values, the development team will give more priority to US #01 and #05 , which are related to cart management. These are the USs that are of most interest to the user and require less effort from the team. Then, US #06 , US#03 , and US #04 ​​will follow , ending with US #07 and #02 . It is important to note that these values ​​are not fixed and can be updated at the end of each sprint.

Urgent Technique

In [3] they propose prioritizing the backlog using two dimensions, but they change the concept of StoryPoints for another one: the urgency in having a functionality ready. Values ​​from 1 to 5 are introduced, where 5 implies that this US must be ready now or else it will lose its meaning, while a value of 1 indicates that there is no hurry to have it ready. Also taken into account for this urgency value is whether the functionality has to be developed for contractual reasons, or because many other US depend on it, so it must be implemented sooner. The Business Value follows the same scale and values ​​from 1 to 5 are assigned. Once all the assignments have been obtained, the urgency values ​​are multiplied by the Business Value values ​​(obtaining numbers between 1 and 25) and are placed in a table like the one below (source provided, [3]):

Given this table, the prioritization is evident: first the US in the red sector, then orange, yellow and finally the green.

Returning to the example of e-commerce, the following values ​​can be assumed:

US Business Value Urgency Sector

Using this technique, the development team will start with US #01, then attack US #05 and #06. Finally, US #02 and #04, and finish with US #03 and #07. Compared to the previous technique, US #06 has been given a higher priority, as with this view, making the shopping cart easy to use has been rated as more relevant. Similar reasons can be used to justify the higher priority of US #02 this time. The ability to navigate the site for guest users has been rated with a high urgency value, so its final priority has been raised.

Other known techniques are:

● MoSCoW: Proposes labeling US with:

○ M: This functionality must be (MUST).
○ S: This functionality should be (SHOULD).
○ C: This functionality could be (COULD).
○ W: This functionality will not be available now, maybe in the future (WON’T).

Then, the US are carried out following this classification: first the US labeled with M, then with S, thirdly those with C and finally those with W.

● Risk-Based: This technique simply proposes doing the USs that involve the greatest risks first. This implies carrying out a complete risk analysis before prioritizing the backlog.

References: