The backlog represents blooming ideas

The backlog represents blooming ideas

Many discussions of product backlogs begin with the assumption that a backlog exists, but where does it come from? Whether you are building a new application or starting a new enhancement project, you need an initial backlog and many times that means that it needs to be developed. In most cases the initial backlog is not going to be delivered by the tooth fairy or by the product owner. Generating the initial backlog requires an investment of time and effort by the project team. Developing the user stories for the initial backlog can be accomplished in many ways. A few common approaches for building an initial product backlog include:

  1. Interview/Discussion Based – The first group of methods boil down to talking to the people that use the current system or know the business needs for a future system. Interview and discussion techniques gather people together and draw information out. These types of techniques have the benefit of being easily scalable. Interviews and discussions can be done one-on-one, small groups or in large groups.  Groups generally leverage techniques for facilitated sessions such as affinity diagraming or Joint Application Design (JAD).
    All interviews and discussion techniques require some degree of preparation. In informal interviews the interviewee needs to understand the business well enough to ask questions and should have both a goal and a strategy for the interview. Develop a question set for more formal sessions. A defined question set is a necessity for large groups or it is too easy to not get the information you need.  I have used variants of the killer innovations questions found Phil McKinney’s book Beyond The Obvious as an interview framework. The facilitated process detailed in Ellen Gottesdiener and Mary Gormans’s book Discover to Deliver (my review and interview with Ellen and Mary) along with affinity diagraming are two techniques I have found very useful for guiding facilitated sessions.
  2. Observation/Documentation Based – Observation and documentation techniques are very useful in scenarios where there is a current manual process that is going to be automated or where interviews are difficult to schedule. Observation allows the observer to watch how work is done with the benefit of not having to rely on what can be described in an interview.  Interviews are subject to interpretation and cognitive biases. The downside to observation is that it is difficult to scale and is most effective when you use trained observers. Documentation techniques done by reading and reviewing system and user documentation, code and other system artifacts (like user interfaces and reports). [FRAGMENT] The review generates the requirements for the new project.

The goal of interviews, reading documentation or observing people working is to generate an initial list of work items. In most cases we are targeting getting just enough of the stories to get the project moving. The work items that are captured need to formatted and groomed just like any other backlog item. Backlog items should be formatted using the standard user story pattern (persona – goal – benefit), should be estimated and should have acceptance criteria.

Where do you get your initial product backlog?  The process begins by collecting needs and requirements.  These needs and requirements will be both business and technical nature.  Once you have this data you can apply standard user story grooming techniques.  For example, we can use story mapping to help drive the needs collection by mapping the information in order to expose gaps.  All of these techniques require one basic input – business needs and requirements.