Gemba walks are a powerful tool for identifying improvements to how an organization does work. At the core of the technique is observation. Seeing provides a basis to compare how people are working to expectations or the process manual. Many change leaders state that change leader should not make changes until they have seen the process in action. In an even more radical approach, some have proponents of Gemba walks have suggested not discussing an issue unless they have observed it. Observation makes a Gemba walk work. Observation is a skill that requires preparation, structure, and practice to be repeatably effective. (more…)


Putting the parts together!

Putting the parts together!

Hand Drawn Chart Saturday

Techniques for building an initial backlog can be classified by how the conversation between stakeholders and the project team is initiated. Some techniques are focused on asking, other techniques focus on observing, while the third category is all about showing something and getting reactions. Most practitioners blend the best from each of the categories. Here are some examples of the hybrid techniques:

Role Playing Prototype: This technique blends paper prototypes (show) with role-playing (observe) to get users and stakeholders to consider how they might act in an environment that has not been fully designed.

Straw man/JAD: This synthesis seeds a JAD session (ask) with an loose outline of a solution or set of potential solutions that are used to guide the discussion which are at the core of JAD. However, the seeding tactic can inhibit creativity. The technique is less constraining when a set of competing solutions is used as the conversation seed, however developing the range of solutions before the JAD session  increases the cost of the JAD.

Embedding: This techniques puts team member(s) into a department to actually perform the work (observe) alongside actual users and stakeholders. This generally requires the embedded team member to be trained and mentored to intimately see how the work is done. I have seen debrief sessions added to this technique to ensure that participants get a chance to discuss the nuances in the workflow.   As I have noted before, with any observation technique everyone needs to understand what is going on and why. This is not an episode of Undercover Boss.

Combining tactics from different categories of techniques that teams use to develop an initial backlog can fundamentally change the dynamics of the requirements definition session. A group of stakeholders will generally have a diverse range of learning and interaction styles that they favor. Combining backlog building techniques gives the project team a better chance at making a connection. Combining techniques should not be done randomly or an ad-hoc basis. Selecting which techniques to combine has four prerequisites:

  1. Someone with experience and training (perhaps a business analyst).
  2. A knowledge of the user community (knowledge the product owner can provide).
  3. Planning (time and effort).
  4. Involved users and stakeholders (call on the product owner and project sponsor to help with this prerequisite).

Developing an initial backlog is a step to get projects going and moving in the right direction. It is, however, only a first step. Backlogs will evolve. Teams, product owners, users and other stakeholders will gain knowledge and experience as the project move forward that will continually shape and reshape the backlog.

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.

Got Soul?

Found art can be fun, uplifting, profound, stupid, irritating or just plain silly but for it to “be” anything you have to see it. Talk less, observe more and have soul!