This is how we collaborate to create the product backlog in my current project. Having a set of stories that will make up the backbone of the project, the product owner is given 1000 points to distribute between the stories. The most important story gets the highest number of points. The second most important story gets the next highest number, and so on. The total number of points used may vary depending on how many stories there are. The product owner disregards complexity or dependencies to other projects. Only business value is considered.

With this as input we have the beginning of a product backlog, a list of stories for the project sorted according to importance to the product owner.

The next thing we need is estimates for the stories and a check to see if there are any dependencies that may alter the order of the stories in the product backlog. We do this by putting up a big piece of paper on a wall (actually a lot of sheets taped together) and then draw a y-axis and an x-axis. We label the y-axis “complexity” and the x-axis “importance”.

The complexity-axis is then divided into 4 sections marked 13+, 8, 5, and 3-. These sections match the number of story points used for most of the stories on our project. The story points denote the relative complexity of a story compared to the others.

We then take the story with the highest importance ranking, put that on a post-it note, and as a team we estimate the relative complexity of that story. Here planning poker is a good idea to try. The card for the story is then placed to the far right on the planning sheet and placed in the section of the complexity-axis that matches the number of points given to the story. We continue to do so with the second highest importance ranking and so on, moving farther and farther to the left on the diagram. The result looks something like this:

This diagram is a valuable tool in creating a good product backlog.

• It provides a quick way to estimate a large number of stories. Having no more than four levels of complexity is a constant reminder that we don’t need to get into too much details. When the discussion starts to drag on, just ask yourself whether the answer will move the post-it up or down one level on the complexity axis. A lot of the time the answer is no. Time to move on to the next item.
• It visualizes the relative complexity of the stories in a way that is very helpful when discussing how complex a story is compared to others.
• It provides hints on possible changes of the order in which to develop stories – a less important story with lower complexity might be preferable to start with than a story with higher importance and a higher complexity estimate.