What is the Agile Development Backlog and what role does it play in the prioritisation of product requirements?

The Agile Product Backlog

A 59 Seconds Agile Video Animation

The Agile Product Backlog with 59 Seconds Agile

The Agile Product Backlog for Developers

A 59 Seconds Agile Article

Agile Development Backlog: What is the Product Backlog?

The product backlog is a collection of prioritized requirements that need to be completed in a project. Once everything in the backlog is finished, the product is considered complete. However, a scrum team cannot work on every requirement at once. As such, the product backlog is prioritized. Higher priority requirements are placed higher in the backlog than lower priority requirements. These high priority requirements get worked on earlier in the project.

Priority of requirements is based on several different factors. The most important factor is value. Another way to describe value is how much stakeholders benefit from a requirement. In Agile software development, the top goal is delivering value to stakeholders. Therefore, working on requirements with a higher value is more profitable than lower value requirements. These high-value requirements are worked on early in the project, while other requirements can be completed later.

In addition to value, several other measures determine the priority of requirements. Risk and uncertainty refer to unknown information about requirements. Things like potential setbacks increase priority since working on them early in a project gives more time to sort out issues. Development time, including size and complexity, also determine priority. Larger and more complex requirements require more effort to finish. Placing a higher priority on these requirements gives the team a longer window to finish them. Dependencies, where requirements may rely on each other to work, also increase the priority. Development of modular code means that subsequent requirements can depend on code that is already finished.

Agile Development Backlog: Developer Role in Prioritization

The Product Owner is normally in charge of backlog prioritization or managing the backlog items. However, the developer role can help in the process. The value facet is solely the responsibility of the Product Owner. It involves interfacing with stakeholders, which is something that developers rarely or never do. The other measures do benefit from developers, though. Development time relies completely on developers. Being the role who handles the creation of new code, the developer has the experience to make estimates. Given a description and specification, a team of developers usually knows how long any given task should take.

Beyond development time, developers also have the expertise to comment on other measures of priority. With risks, developers have an intuition about issues that may occur or possible setbacks. Among a team of developers, at least one is likely to anticipate an issue, and discuss it with the team. Similarly, developers have a better understanding of dependency. They know what code can be modular, and what tasks benefit most from early development. By writing core code first, later tasks require less work to be completed.

Tools for Prioritization

While prioritizing the product backlog, a collection of prioritization tools may be used. The MoSCoW method is one of the most commonly used prioritization tools. MoSCoW is an acronym for “must have, should have, could have, won’t have.” These are 4 categories to sort tasks into. Some tasks are absolutely required, and so the customer must have them. Other tasks would be very nice to have, but not explicitly necessary, so the stakeholders should have them. Tasks that would add to the value of a product, but are a lower priority than must have or should have tasks fall into the could have area. Lastly, any tasks that will not make it into the next release are won’t have. By placing all tasks into one of these groups, the tasks are sorted into a general order of importance.

Prev <— Continue Reading —> Next

Learn More: Agile Product Backlog

Learn More

User Stories Applied

A 59 Seconds Agile Book Review

User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.