Project Prioritization 

There are two levels of prioritization for agile. The first is the product backlog – the prioritization of the scope of the project.  The second prioritization is how we populate the sprint contents.  The top priority product backlog items are used for the decomposition for the sprint, but there may be prerequisites that must be included in the sprint; that are not specifically called out in the product backlog, technical prerequisites for example.

Return on Investment

When it comes to the product backlog, cost and value determination there are at least two ways besides ignoring.  The first is more traditional look at the entire project costs compared with the return.  Using this approach we batch the estimated cost against the projected (also estimated) revenue generated.  

Agile and Prioritization

The second approach more agile friendly, and should be a significant input to the product backlog prioritization, is a more incremental approach. That is, instead of looking at the entire project, look at the cost and value for each requirement / user story and compare that to the estimated return or revenue generated (ROI).  That allows the product owner to prioritize the product backlog based upon the projected money brought back into the organization and the value of the product backlog item received by the customer, ensuring the team is working on those parts of the product that provide the greatest value.

Study of ROI and Requirements

This graphic below is from The Chaos Report 2015 from The Standish Group[1].  In this study of 300 companies, we see that 15% calculate for the overall project and then distribute that over the individual requirements, presumably based upon the estimated magnitude of the individual requirement. Only 14% calculate for each requirement and then sum that for the entire project. Those that take this approach will know the cost for the individual requirements which is the cost half of the equation.  At this point we need to understand the value to the customer (and by extrapolation our organization) and we will be sufficiently armed to answering priority questions.  

The limits

The problem with the batch approach, whether you are using an agile approach or a conventional approach to the project, is the inability to prioritize the individual specific objectives.  In other words, we are unable to specifically and readily identify neither the value of nor the cost of each of the use cases or requirements.   Therefore, prioritization of the backlog and sprint are performed at a higher level of abstraction or based at least in part on intuition or subjective assessments.  The same would be true for conventional projects, we have not clear demarcation of the important parts of the project from lesser.  Subsequent blog will demonstrate this difficulty.