Software Development Project Backlogs Explained
The product backlog is the list of features or work to be completed for a project. In software development, product backlogs are typically a collection of user stories (more on those in another edition of this series). Each user story represents a slice of a project that could be completed and delivered within one sprint. The product owner sets the product backlog items in order in terms of priority. The highest priority items fall to the top of the backlog while lower priority items fall to the bottom. Then, in sprint planning, teams pull from the top of the product backlog to the sprint backlog what will be completed during that particular sprint. At the end of the sprint, the highest priority work should be completed and fully delivered, allowing the team to focus on delivering the next priority.
Because agile products plan for fully delivered sections of projects at frequent iterations, it’s beneficial for the product owner to prioritize the product backlog based on the return on investment that the work item will produce. Level of effort required to complete the value should also be considered, so time is best used generating value.
Prioritizing Backlogs for Software Development Projects
So, how does a product manager do this prioritization to ensure return on investment? There is a simple formula that we can use to determine the order.
Return on Investment = Business Value/Effort
This sounds like a simple enough formula, but how do you put this in to practice? Here is a method that has been shared with me that I’ve found valuable. Once you have your user stories (or requirements, if in another format) written, place them in a list. Then, determine a relative weight for both the business value and the effort that it would take to complete (story points is a great fit here). Finally, perform the calculations to determine the ROI rating, and then prioritize based on that number.
I use a relative number for estimated business value generated. In the example below, I am using a scale of 1-10 to rate anticipated business value and story points for the effort estimation. As you may recall, it’s the product owner’s responsibility to stop the project when a great enough return on investment is not being met by the level of effort required. In the example below, the threshold set was 1.5, so you’ll notice we will not be pursuing User Story D at this time. User Story D will remain on the product backlog as business value for the story could increase or effort could decrease, which could affect the priority of the story.
User Story Business Value Effort ROI Rating Will we do it?
User Story A 10 2 5 Yes
User Story B 6 2 3 Yes
User Story C 8 5 1.6 Yes
User Story D 5 5 1 No
There are many ways to prioritize the product backlog, but this method ensures that you will generate the most return on investment in the shortest time possible. Consider using this tool next time you are working to prioritize your project work.