Agile DevelopmentGuest BloggerProduct Management

My Agile Product Backlog Template

By Rivi Aspler

When I started using Agile, I was looking for a good backlog template. Naturally, I found several examples online, each very different from one another and none that really fit my needs. The template that this post is dedicated to had started with one of those online templates and since then has improved, to a level that we (at Synerion) find to be good enough. To cut a long story short, I hope that this post can save you some search time … 😉

Now let’s move on to the practice….

We use an Excel spreadsheet to list the various user stories (which are then detailed furthermore). In the past I’ve used several types of dedicated software products that are targeted at exactly that, but you know what… good old-fashioned Excel isn’t that bad.

Roles that use the Excel spreadsheet

  • Product Owners  – use Excel to list their requirements
  • R&D team leads  – use Excel in order to estimate the effort per requirement
  • Knowing the pre-defined capacity per product – Product Owners then use Excel in order to ‘move’ features between releases (hence defining the release backlog)
  • And last but not least, managers use Excel (or charts that are based on Excel) to monitor the entire process

Columns in spreadsheet

(click to enlarge)

Columns Descriptions

  • Backlog – this is the order by which R&D should develop the product.
  • TFS – this is the requirement ID as the end-developer knows it.  We use MS Team Foundation Server in order to manage the product life cycle. There are many other types of software out-there.
  • Role – explains to R&D who should use the feature.
  • Screen – makes sure that everyone knows which screen are we talking about (don’t laugh. When you have lots of screens, a developer may start working on the wrong screen…)
  • Theme and Epic– Assist the PO and the developers to understand the topics hierarchy better. You can read more about these Agile notions here.
  • User Needs – is an actual definition of the user story. You may want to note that in pure Agile this concise definition is sufficient in order to code the user story. I’ve found that you as a PO would want to detail the user story furthermore, making sure that the developers do exactly what you want them to do.
  • EE – stands for Effort Estimation. This column is filled by R&D and unfortunately will ultimately define the product’s release-scope. When a PO has 6 developers to whom she can assign work, the release scope will naturally be different from when having only 4 developers to assign work to.
  • Release Date (in this example, Q4.12 and Q1.13) – allow the POs to move features between releases, based on their big-stones, their commitments to customers and R&D effort estimation.

Several Products = Several Backlogs
Each product has its own backlog and hence, if you are managing several products, adding more spreadsheets to the Excel is the easiest way to handle more than one product.

Good luck with your backlog.


Tweet this: My Agile Product Backlog Template http://wp.me/pXBON-3De #prodmgmt #agile