How to Prioritize Work in Agile

The artifact that is crucial in prioritizing an Agile team’s work is the product backlog. Simply put, the product backlog is a list of user stories ordered from most to least important (Rose). The specifics of the user stories will depend on the end product a team is working to produce. The following image is an example of a product backlog for a generic website:

Unlike traditional project management, where teams depend on established, rigid requirements before they start work, the backlog in Agile is a flexible, constantly-changing document (Rose). An Agile product backlog is subject to the will of the product owner, who can alter or add work to it as he or she sees fit (Rose).

(Image from: http://www.scrum-institute.org/The_Scrum_Product_Backlog.php)

How to Begin a Product Backlog
As a product owner, the best way to start off a product backlog is by first developing a few high-priority user stories (Rose). Though the stories may initially be vague or eventually require some breaking-down, Agile allows for the backlog to begin this way, but then eventually get better through refinement, clarification, and updates. If the work laid out by the product backlog gets to be too much, the product owner is free to “replace, relist, and re-prioritize” the work (Rose). Furthermore, the product backlog should function incrementally and require a task to be fully completed before moving onto the next (Rose).

How to Refine a Product Backlog
The product owner should work on refining the product backlog numerous times a week (Rose). However, before a product owner begins backlog refinement, he or she must first start by adding stories to the backlog and then narrowing them down to produce a clear list (Rose). This process is called “backlog preparation” (Rose). Once this initial step is complete, the product owner can then begin refining by updating the items on the backlog and clarifying the stories further. The product owner should collaborate with the team to refine the backlog for 4-8 hours a week (Rose). The collaboration should begin with the product owner presenting the developers with some of the user stories and should be done in an environment that encourages open discussion (Rose). Developers should then work to deeply understand the user stories, but ensure that they leave the decisions for how they will deliver for sprint planning sessions (Rose). A good guide for the characteristics a project backlog should possess is D.E.E.P. "Detailed appropriately""Estimated""Emergent""Prioritized"

(Image from: https://leanpub.com/MasteringBacklogs/read)

Product backlogs should be detailed appropriately enough so that they are well understood and can be completed in the next sprint (Rose). The backlog should also be estimated in the sense that it is not just a task list, but a “planning tool” in which the team estimates how much work the user stories will require (Rose). Since the highest priority work is at the top, the further down the backlog one goes, the rougher the estimate for the user story is allowed to be. The emergent characteristic stresses the aforementioned flexibility that a product backlog should have. The estimates given to the product owner will likely be a push for the user stories to be reorganized and therefore, for the backlog to change. Lastly, the backlog should be prioritized, with the most valuable items at the top and the least valuable at the bottom (Rose).

How to Prevent Chaos
Unfortunately, not all organizations will value the authority of the product owner over the backlog as they should. Due to this, managers may be given permission to add or remove work, which can easily result in chaos because the developers each end up working off their own unique backlogs. Such a lack of cohesiveness often leads to a quite chaotic project and can sometimes cause a team to disband (Rose). Working in this manner is a recipe for failing to complete a project. For a project to the most effective, the product owner should be the one who manages all the team’s work and coordinates with stakeholders to explain why some tasks are deemed more important than others (Rose).

Works Cited

Rose, Doug. “Keeping Agile Transparent.” Lynda.com - from LinkedIn, 23 Nov. 2015, www.lynda.com/Business-Skills-tutorials/Keeping-agile-transparent/175962/452757-4.html.