Estimating Product Backlog Items (PBIs): Before or after Prioritizing?

Just reading the title, probably the first question that comes to your mind is: Why the first post those guys are writing, related to Product/Project Management subject, tackles directly this topic? :)

The reason why we are not trying to explain “everything” about Product/Project Management (PM) processes using a common top-down approach is because it would probably lead to:

• Writing an endless documentation that you may already know at 95%.
• Repeating basic notions that surely other people/teams with more knowledge and experience can do better than us.

In consequence, the aim of this and future posts is to share the practices that at ZALEOS we have identified as the most appropriate ones (at least with proven results in our case) in order to deal with the most common challenges that Product/Project Management (PM) teams have to face during Product lifecycle.

We hope it can be useful, specially for those of you who have started facing those challenges for the first time ;)

1. Context

In order to put things quickly into perspective, we would like to refer to the 3-levels definition that Kenneth S. Rubin describes in a very illustrative way in his book “Essential Scrum: A Practical Guide to the Most Popular Agile Process” (chapter 7),

Basically, according to that, there are 3 different levels at which Agile teams should work when going across the path which starts with Business Requirements and results in Development Tasks:

• Portfolio Backlog: List of products/projects to be built.
• Product Backlog: List of Product Backlog Items (aka User Stories) associated to each Product/Project which need to be implemented.
• Sprint Backlog: List of tasks associated to each Product Backlog Item (PBI) which need to be developed.

The topic we are going to tackle in this specific post only describes the challenge of defining which of the following phases - run at Product Backlog level - should be executed first: Estimation or Prioritization.

2. Estimation and Prioritization: Which one first?

According to the practice most commonly followed and supported by many Agile teams, the Estimation exercise (aka Sizing) should be run only with prioritized Product Backlog Items (PBIs) within the Product Backlog.

This can make sense from PM and Development teams’ perspective because Estimation exercise has an associated cost in terms of time and resources, so it’s not efficient to try to keep always the full backlog of PBIs up-to-date (specially considering the risk that some of those could be cancelled in the end). However from Customer/Stakeholders point of view, the following (fair) questions can arise then:

1) The Prioritization also requires a cost in terms of time and resources on our side (Customer/Stakeholders): Which is the best approach to run this phase in the most efficient way?

2) What happens if some of the priorities set must be revisited after doing the Estimation?

(Yes, that’s a fair point! If a nice-to-have PBI with a big size is likely to be removed from the Product Backlog, PM team should help the Customer/Stakeholders making that decision as soon as possible).

In order to address all those needs and to ensure resources from all the teams involved in the process (Customer/Stakeholders, PM and Development) are managed in the most efficient way, the solution our team has chosen in that case is the one described here below:

Basically, in a nut shell, the goal is to run in first place a “quick and easy” Prioritization and then Estimation/Sizing in order to initialise the process (“to start the engine”), so it can be easily and progressively tuned up in future iterations.

Now, let’s do a quick overview of the different stages described above.

2.a) High-level Prioritization

• This task is run by the Customer/Stakeholders - with some degree of involvement also of the PM team - for all the PBIs defined in the Product Backlog, taking into account only the business needs as inputs for that calculation.
• Due to the lack of inputs at this stage and the fact that the cost of running this exercise by the Customer/Stakeholders should be the lowest possible, the level of granularity of the initial priority should be a rough value (basically based on the level of criticality each PBI has from business point of view).
• As mentioned by Matthew Heusser in his article “6 agile methods for backlog prioritization”, there are different methods and scales which can be used to run this exercise (e.g. MoSCoW model, “Weighted shortest job first”, etc.) but we will talk about that in a future post as it deserves a thorough discussion.

2.b) Estimation/Sizing

• This task is run by the PM team - with help of the Development team - only for the PBIs in the Product Backlog with a “high-level” priority attached to them, due to the fact that it also requires a cost in terms of resources and time for PM and Development teams, so that cost should be the lowest possible too.
• At this stage, without knowing yet which are the Development Tasks associated to each PBI, the level of granularity of the Estimation/Sizing should use a scale which measures the “size” of those PBIs (“how big are they”), instead of the “ideal days”.
• There are 2 possible (outstanding) methods to size a PBI which, by the way, we will discuss in further detail in a future post:T-shirt method (option #1): Assigning values such as XS, S, M, L or XL.Story Points (option #2): Assigning values using an adapted version of Fibonacci Sequence (i.e. 1, 2, 3, 5, 8, 13, 21).

2.c) Detailed Prioritization

• This task is run again by the Customer/Stakeholders - with the help of PM team - only for the PBIs in the Product Backlog with “high-level” priority and “size” attached to them.
• At this stage, a more granular priority should be set in order to get, as a result, a sorted list of PBIs. For instance, a “rank” where the lower number (1) represents the PBI with the highest priority and the higher number (N) represents the one with the lowest priority.
• This value can be tuned up in every iteration (business needs and priority can evolve), until the Release Planning meeting takes place and the scope of PBIs for next Release version is “frozen”: At this point, the priorities should not be changed anymore (the cost of rolling this back is very expensive!).

3. Conclusion

There are many different ways and approaches to define the order at which Prioritization and Estimation should happen at Product Backlog level, but at Zaleos we have decided to apply the solution described in this post because we think it provides a very good tradeoff:

• Customer/Stakeholders, PM and Development teams can benefit from a high flexibility when running those phases (without adding roadblocks).
• The associated cost is minimal because the resources are managed in a very efficient way.