If you are applying Agile, then there will be a product backlog. There are many ways to apply Agile, but most of them will revolve around a product backlog.

So, with the product backlog being such an important piece of Agile development, it is important for you to know what it is and how to create one.

What Is a Product Backlog?

A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. You can think of a product backlog as a long list of things that must be done to successfully create the software.

The most important items are shown at the top of the product backlog so the team knows what to deliver first. Once the product backlog is established, the development team pulls work from the backlog. Depending on what Agile method the team is using, they may pull continually (Kanban) or by iteration (Scrum).

What Goes into the Product Backlog

You want to avoid cluttering the product backlog, so, there should only be work that directly affects the finished software. What this means is that the bug fixes, new features, small updates, and technical debt will be grouped together as “user stories”. User stories are short requirements written from the perspective of an end user. An example of a user story is “Android users need access to a vertical view of the live feed when using the mobile app”.

The product backlog should be composed of a bunch of user stories organized by the product owner.

Prioritization

There are many things that may influence a product owner’s prioritization. Here are a few to consider:

• Relative implementation difficulty

• The urgency of getting feedback

• Customer priority

• The relationship between work items (e.g. B depends on A being done or B is easier if A is done first)

Although the product owner sets the priority of the user stories, it’s not done alone. Effective product owners seek input and feedback from customers, designers, and development team when deciding on prioritization of stories.

Making Good Estimates

It is a good idea to give an estimate to each user story. When user stories are accompanied by good estimates, it helps the development team decide on how many user stories to pull from the backlog. This ensures that the team is not overcommitting.

Here are some tips to make better estimates:

• Start estimating the top priority backlog items. You don’t want to spend time on estimating low priority items that the team may not work on in the foreseeable future.

• If the user story is too difficult to give an estimate then it is probably too complex. Break it down into something smaller.

• Focus on the average number of hours the team can handle as a whole. The team will have a mixture of new and experienced developers. It may take the new developer 5 days to complete something estimated at 3 days to do. On the other hand, an experienced developer may take 2 days to do the same thing.

• Keep backlog items independent of each other as much as possible. You don’t want to introduce a layer of complexity that doesn’t need to exist.

Identify When Something Is “Done”

This sounds simple, but it can really trip a team up towards the end if there is no universally accepted understanding of what it means to complete a user story. Consider the case when a developer says the user story is “done” because he or she finished coding it. Has it been tested? Reviewed?

To avoid a scenario like above, develop a brief checklist that outlines the definition of “Done”. The checklist should ensure that an item has passed through the necessary workflow steps, received a final level of review, and is ready for shipment.

What are your experiences with the product backlog or Agile development? How do you and your team break down the product backlog?

To stay in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.