Most professional software development shops, AndPlus included, have adopted some variation of the Agile development methodology. Among the most important concepts in Agile is that of the product backlog, which is simply a list of items (front-end features and under-the-hood tasks) that need to be implemented in the software product.
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.
Too Many Cooks…
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:
- Marketing may want certain features released sooner than later to provide a competitive advantage.
- Developers may recognize that certain front-end functionality requires a good deal of back-end work be completed first.
- Software testers may say that certain features need to be implemented before others so the test cases make sense.
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:
- The complexity and risk of implementing a given feature.
- The team members’ skill sets.
- Technical dependency relationships among the backlog items.
- Expected return on investment for a given item.
- Voice of the customer, the competitive landscape, and other market forces.r
Failure to consider all the angles runs the risk of having unrealistic and unmet expectations, which hurts morale and can derail a project.
When to Reset the Priorities
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.
