How to Create an Effective Product Backlog for Your Agile Team

Eugene LaiMon, 01/21/2019 - 11:33

Are you thinking about converting your project management approach from traditional/Waterfall to Agile? If so, one of the key things you will need to learn is how to create a plan of attack for your project, starting with the project scope.

There are many interpretations on what a “project scope” actually means. For the purposes of this article, we will consider project scope to be “all work necessary to deliver a meaningful and valuable product or service to meet a business objective.” Within this context, most projects that I have managed in the past typically have the concept of a WBS (Work Breakdown Structure), which may take different forms; some Project Managers follow a phase approach where the work is grouped by time/phase, others may prefer to use a deliverable-based approach where work is aggregated by the work product. It’s possible to convert either structure to an Agile-friendly format. Below are a few ideas for your consideration.

  1. Start with the vision – Most projects have some business objective tied to them, whether it’s generation of new revenue, expanding into new markets, reducing cost by improving efficiency, etc. An Agile project still needs that focus in order to define the work and the desired outcomes in a meaningful way. The vision sets the tone for the project team, and allows the team to evaluate progress towards that bigger picture strategy.
  2. Define capabilities & features – Using the vision, the project team should be able to define the high-level system functionality and decompose them into smaller units of work (for a product development project). For a service/solution-oriented project, this may take the form of customer business processes and/or capabilities. Typically, capabilities may take several months (usually more than 3 months) to complete, whereas features are generally scoped to the scale of a few weeks.
  3. Define user stories – Once features are identified, you can start building User Stories, which are user-centric narratives that model after a business process flow. This is an area where many new Agile teams struggle, most likely due to lack of experience and/or training. It is not uncommon to see a product backlog filled with tasks/activities instead of User Stories, which can create problems during implementation.

Let’s elaborate a bit more on User Stories. The practice of User Stories originated from XP (Extreme Programming), and is designed to help the project team take the perspective of the end user. The process of writing User Stories provides significant benefit because it encourages the project team to make an effort to understand how the end consumer of the solution they are building will experience the product. Taking the viewpoint of the end user is critical in ensuring that the end solution isn’t simply “cool”, but provides a positive experience and meaningful business value at the same time.

It is very common for new Agile teams to create a backlog of tasks, which is a great place to start, but creates risk to the project due to erosion of the user perspective. Tasks are things that the project team must do to design, create, test, and deliver the end product. While having a solid understanding of the activities that the team must take on, focusing solely on tasks creates a dynamic that emphasizes the internal activities instead of the customer. This practice also creates challenges during a demo (either for the project team or the customers) because the customer perspective is lost, and perceived value will likely be diminished.

In closing, I encourage new Agile practitioners to carefully study User Stories, which is a skill that requires persistence and time to master. However, this is an important investment to make if you want to be successful in applying Agile approach.

Just a note, ASPE (the publisher of this article), does offer a User Story Workshop that provides extensive instruction and practice on defining and managing requirements as well as alternatives for managing changes. This is a 2-3 day course, offered nationwide, live online, and as a private, onsite delivery. You can learn more at