Generally Agile's development work is divided into iterations. In Scrum these iterations are known as “sprints”—short (usually 1-3 weeks, we almost always do 2 weeks here at AndPlus) development cycles. At the end of each sprint, the team should have fully tested, bug-free, working software that, at least in theory, could be released to end users. (The decision on whether to actually release the product to users depends on numerous factors that are beyond the scope of this article.)
Items in the backlog are typically broken down into smaller tasks, and each sprint includes a set of tasks that the team believes can reasonably be completed within that sprint. Because of the short duration of each sprint, no single sprint can include all of the items on the product backlog. Thus, the the product owner must prioritize the backlog items and decide which ones are included in each sprint. This is where things can get muddy.
Prioritizing the backlog is among the most critical tasks that must be done before any development work is started on a project. Many factors must be considered when prioritizing the product backlog, and each stakeholder in the development product may have a different opinion. For example:
In an Agile environment, every software product has a Product Owner, whose responsibility (among other things) is to make the final decision on the backlog priorities. But the Product Owner is well advised to consider the opinions of the other stakeholders before deciding. Among the aspects that should be considered are:
Failure to consider all the angles runs the risk of having unrealistic and unmet expectations, which hurts morale and can derail a project.
Any software of at least moderate complexity involves numerous sprints to implement all of the backlog items. The priorities that made sense at the beginning of the project may not work so well after a few sprints. There are several possible causes, such as changes in the competitive landscape, “discovered work” (unanticipated effort or complexity in implementing certain features), the departure or addition of stakeholders, and more. It would be foolish to pursue priorities that don’t make sense anymore, so it’s wise to re-evaluate the priority list periodically.
How often should this be done? That varies from organization to organization and project to project. Many organizations do it on a calendar basis, such as once per quarter; others when problems with the current priorities become apparent. Once per sprint is generally seen as too frequent, because the constant shifting of priorities complicates long-term planning and project management.
It all comes down to the team’s comfort level and experience. A team might need to try several schemes before settling on one that works for them.
Product backlog management is one of the most important activities in an Agile software project. It takes some practice, but getting it right spells “success” for an Agile team.