Neil Crookes

Learnings and Teachings on Web Application Development & CakePHP



Creating the product backlog

Previously I blogged about what user stories in scrum should look like, providing an overview of their format and principles, but not really covering a how you come up with them all or how you decide what order to do them in.

This post covers who needs to be involved and recommends a practical 10 step approach for creating the Product Backlog.

Share and Enjoy:

  • Digg
  • StumbleUpon
  • Technorati
  • Slashdot

What is the product backlog?

The product backlog is a prioritised list of user stories, in the format “As a <user type>, I want to <do something> in order to <get some benefit>”, including a value of their size and complexity.

In order to prioritise the stories in the backlog, the product owner needs to have an appreciation of both the value and the size and complexity of each story in order to gauge the return on investment it offers.

When should the product backlog be created?

You can’t do anything until you’ve got a list of things to do, so the creation of the product backlog is the first thing that should happen on a project.

Prior to this, the only things that can be done are things like competitor analysis and research into user roles and objectives etc.

The product backlog is created at a project kickoff meeting called the story extraction ceremony.

Who creates the product backlog?

The Agile Manifesto talks about individuals and interactions, customer collaboration and face to face communication.

The whole product backlog can be created in one meeting, provided all the required stakeholders are represented. These are:

  1. The product owner – this person is ideally the client, but if they do not want to be involved it can be a member of your team, e.g. the client’s account manger, but they must precisely understands the client’s industry, business, customers, objectives and vision. This is because questions will inevitably arise that only someone who fully understands all of these things will be able to answer.
  2. The facilitator – this person chairs the meeting, making sure agenda items don’t overrun, records the stories identified, their priority and size/complexity values. It’s normally the Scrum Master.
  3. The production team e.g. designers and developers – in order for the product owner to prioritse stories, they need to know the effort required to achieve them so they can make a value judgement and identify the relative return on investment. In order for the production team to estimate effort, they will inevitably have questions about the stories that only the product owner can answer.

This process will not work – guaranteed – if all these stakeholders aren’t represented.

Other’s can attend, e.g. business analysts, subject matter experts etc etc.

How do you create the product backlog?


  1. The Scrum Master arranges a meeting for all stakeholders mentioned above and ensures a whiteboard or flip-chart, index cards or post-its and a digital camera are available.
  2. At the meeting the Product Owner states the objective(s) of the product and answers any questions from the other stakeholders present until everyone is clear (15 mins max).
  3. The facilitator invites and records on the whiteboard or flip-chart, suggestions for the values or benefits to the potential users of the product and the scrum master takes a picture (15 mins max).
  4. With reference to this list the team suggests user roles who are interested in attaining these values or benefits from the product and the facilitator records them on the whiteboard or flip-chart and the scrum master takes a picture (15 mins max).
  5. Either altogether or in smaller groups, depending on time and number of user roles and values, the stakeholders identify as many user stories in the form described here for each user role identified in (3) and each relevant value or benefit identified in (2) and record them on index cards or post-its.If done in smaller groups, each group in turn states their stories and answers questions until everyone is clear, rewriting the story if necessary.

    Once accepted, the story is placed in a pile in the middle or group.

    Note if at any stage more objectives, values/benefits, user roles or stories are thought of (which is likely as further discussion generates further ideas), they should be added to the lists. (1hr 30 mins max)

  6. Product Owner categorises stories into “Must have”, “Should have” and “Nice to have” in terms of the value to their business that each story will offer. Value can mean financial or be more abstract, whatever the client wants. If you’re using index cards just group them in three clouds on a table, but if you’re using post-its, stick them up on the whiteboard under the three headings and the scrum master takes a picture (15 mins max).
  7. In order of priority, the production team assign story points indicating the size and complexity of each story. I’ve blogged previously about how to estimate stories quickly.Agile is also about mutual trust, so doing this in front of the client should be OK, but if you’re apprehensive about it, consider just categorising stories in terms of “Simple”, “Moderate” and “Sophisticated”.

    Place each story in the relevant square of a grid with the priority going down the vertical axis and the story points or sophistication level along the horizontal axis, e.g.

    0 0.5 1 2 3 5 8 13 20 40 100
    Must Have
    Should Have
    Nice 2 Have

    This best done up on a wall so everyone can see it easily rather than on a table where some people might be looking at it upside down. So unless you have a massive notice board with this grid on that you can pin index cards to, you might be better off with drawing it on a white board and sticking the post-its in the right cells.

    It is likely that some stories will require some expansion at this stage, the production team will have questions for the product owner, they’ll probably discuss potential solutions. The scrum master should write down on the the story’s index card or post-it whatever is agreed and then takes a picture (1hr 30 mins max).

  8. The product owner, with this new appreciation of the size and complexity (and an inkling of cost) of all the stories in the backlog, may wish to reprioritise some of the stories, or explore alternative solutions, perhaps splitting the story up into a higher priority simple solution and an lower priority enhancement. At the end of this process, the facilitator takes a picture of the grid (30 mins max).
  9. The product owner must now prioritise the stories in sequential order taking stories off the grid in the order of the highest priority first, et voila, the product backlog is born (30 mins max).
  10. The facilitator collects the stories up and thanks everyone for their time.

The whole process should easily be achievable in one relaxed day and be quite fun.

A trimmed down version of this could even be done by your team before you’ve won a client’s business in preparation for pitching for it. And when you’ve won it, you’ve already done half the work!

Share and Enjoy:

  • Digg
  • StumbleUpon
  • Technorati
  • Slashdot
(1 votes, average: 3.00 out of 5)
Loading ... Loading ...

Comments are closed.