Context, rationale, and overview of Story / Impact Mapping

Small batch software development is good

There are many advantages to working in small batches in software development:

• Faster feedback
• Problems are localised
• Reduced risk
• Greater pressure and practice to reduce overhead
• See The Principles of Product Development Flow for more

Naive small batch software development is not quite so good

There is also a significant disadvantage when small batches are done naively: disconnection from overall purpose.

Jeff Patton described this phenomena using the metaphor of a tree versus a bag of leaves:

In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations. 

After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree.

The "bag of leaves" approach to backlogs is a context-free prioritised list of work items, that is, the naive, and I'd argue typical for Agile novices, understanding of "backlogs".  Although it nominally reflects a small batch approach, the "bag of leaves" discourages connection with underlying rationale and purpose, and therefore undermines autonomy.

Where I propose 5 attributes that indicate an effective approach to defining small batches in software development

Instead, a more effective approach goes beyond work broken down into smaller pieces.  A more effective approach...

• Highlights overall intention in the form of goals
• Highlights the logical relationship between goals and the work items that need to be done
• Visually represents goals, work items, and relationships in order to expose potential disagreement or misunderstanding
• Is designed to be done in a collaborative way
• Is iterative, that is, it does not require full completeness at the start

This is how I describe Story / Impact Mapping

Both Jeff Patton's User Story Mapping and Gojko Adzic's Impact Mapping are (mostly equivalent) answers to naive approaches to defining small batches in software development (aka creating backlogs).  This is how I would describe how to do it:

Note: This process should be iterative.  It is only presented sequentially because that is easier to understand.  It is not necessary, nor advised to try to fully complete every step in order.  Instead, start with what you have and jump around and revisit steps as useful.

1. Identify Goals

What are you trying to accomplish?

This should be something observable and therefore measurable.  For this reason, I like the term "impact" given that it implies something that is observable.  However "goal" is more familiar to most people and I generally don't like introducing new jargon unnecessarily.

There may be more than one goal.

2. Identify Roles and Activities

Who has to engage in some Activity to achieve the Goals? OR What Activities need to be done by someone to achieve the Goals?

I generally prefer starting with Activities but in practice, this tends to be a very iterative process.

Note that Role is distinct from Person.  The Person may play other Roles that don't have anything to do with your Goals but rather their own Goals.  This typically means that you will need to add additional Goals that need to be supported.

3. Identify Capabilities

What needs to exist in order for the Role to do an Activity?

A Capability may not need to be something that is built in software.

4. Identify Features and Stories

What needs to be done to create and/or enable a Capability?

Stories should be smaller pieces of work activity; Features are more to allow discussion at a higher level of granularity.