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)

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.

> **D**etailed appropriately
>
>

> **E**stimated
>
>

> **E**mergent
>
>

> **P**rioritized
>
>

(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.