Agile practice recommends to focus on business value. Those items with the highest business value should be implemented first. At the goto zürich conference held in April 2013, one recurring topic was how to prioritize backlog items.
Other practices, e.g. from the Unified Process, ask the team to focus on highest risk items. I briefly mentioned our approach in the article about maturity tools for product owners.
Rating the maturity allows a project team to have a much better discussion about prioritizing backlog items.
The picture above shows the (anonymized and simplified) result of a discussion about backlog items. They key information depicted is:
- the assessed maturity of the backlog item
- the estimated value (min/max) associated with the backlog item
- the dependencies between backlog items
The first spring release is well planned: items are reasonably mature, dependency and order seem to match. The team provides something immediately with some value and thus market the product with a quick success. Great.
The autumn release however seems highly questionable. Everything relies on F5, an item that has a high promise of value but a lot of uncertainty in it. The backlog items of that release need a lot more exploration, before you would want to start with it.
Prioritizing is more than just looking at business value, for sure. Taking maturity and the reasoning behind the maturity into account, can help a project team to lead a more founded conversation about the priorities in a project.
Having used maturity rating from stars to road over the last couple of years, I can add some approaches that agile teams tend to take:
Stars. Agile teams tend to not schedule such items for an upcoming release for implementation. They either delay the item for much later or, if there is a big demand for it, plan for investigations. It needs high urgency or a big promise to schedule an item on star level for implementation.
Clouds. Cloudy items are quite often scheduled for an up-coming release. Usually estimates are high, as the team adds the high risks of the many unknowns. However agile teams also plan spikes and extra refinement work to nail what to do. Agile teams however do not schedule cloudy items for a sprint. The only exception probably are very urgent items. Teams however are willing to schedule spikes and refinement work to bring cloudy items onto tree level.
Overall, the more unclear the value to the agile team the more the item is moved to a later release.
Trees: Developers are usually happy to schedule items on the tree for releases and sprints.