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.

I haven’t been as active writing on this forum as I hoped I’d be. A large part of the reason for this is that I have prioritized other things than writing when I have time away from work. But another important part has been the problem to come up with things meaningful enough to write about. I have dismissed a lot of topics that I have thought to be too obvious to write about. The other day I started to think that perhaps I was wrong.

I’ve introduced sprints in my current project. A sprint runs for a fixed amount of time (in our case two weeks). During that time the team delivers an increment of functionality. The sprint starts with a sprint planning meeting. A big part of this meeting is that the team decides for itself how much of the highest priority functionality will be delivered at the end of the sprint. This is natural as it is the team that is supposed to do the job. The members are the ones who know what it takes. They are best suited to make the decisions. Well, at least I thought that was obvious.

One of the managers in the organization took me aside one day and asked me with a concerned look how I would make sure that the team took on enough work. If the leads of the project don’t push the team to take on more things to do, how can we get them to work fast enough?

I firmly believe that all teams will do its very best at all times. With a team of highly skilled, well trained, and motivated people, why would you need someone to push them to take on more work? On the contrary, most teams seem to over commit in the beginning, wanting to take on more work than they are capable of.

We ask a lot of our developers nowadays. They are not only supposed to just make the code work. They’re supposed to write unit tests, write integration tests, refactor the code, communicate with product owners, communicate with testers, communicate with other developers, and make sure that their changes don’t break anyone else’s code.

What do you get when you push those developers to squeeze some more work in so that we can make the project deadline? Most of the stuff above will be skipped and we will be back to trying to just making it work. In the short term it will look like we’re moving faster, but the lack of quality measurements will sooner or later come back to haunt us. Additions and changes will become harder and harder. Adding tests will be harder and harder. Meeting deadlines will be harder and harder. Skipping anything but just writing code will look more and more tempting.

I thought this was obvious. Isn’t it?