How the big picture gets made…

A high-level narrative or story is a good first step in the process of turning an idea into something that delivers real business value.  However, it is only a step along the path through the backlog onion.  Software development (including new development, enhancements, and maintenance work) requires translating the big picture into a product backlog that includes features and epics.  As work progresses the backlog is further decomposed and groomed into user stories and tasks.  The process of moving from any big picture to a backlog in software development follows a predictable pattern.   

  1. Decompose the big picture by identifying the functional and architectural features directly identified or inferred in the story.  This initial step yields a combination of business requirements and the beginning of both the technical and business architecture that will be needed to support the features.  Features of all types are a description of need and outcome and do not represent a decision on how that outcome will be implemented (real options).
  2. Organize the features using a mapping technique such as Agile Story Maps to look for gaps.  Ask yourself and the team whether there are features that needed to achieve the goal identified in the big picture story.  This also a chance for the product owner to reject stories that are not needed to attain the overall goal.
  3. Identify the minimum viable product (MVP). The identification of a minimum viable product at this point identifies the set of features that are needed to deploy a product.  An MVP begins the discussion of priority and a release strategy.  Simply put, features in the MVP will need to be decomposed before features that will be needed later.

An Agile Story Map and an MVP allow a team to cut a wedge into the planning onion that slices from the outer layers directly to the core.  In the Scaled Agile Framework Enterprise (SAFe) the wedge might be called a Product Increment (PI) or a release for efforts using other frameworks and methods.

  1. Features and epics, while easily recognizable, rarely can be tackled by a single team in a single sprint; therefore, they need to be decomposed or split.  The process of decomposing epics and features breaks these large pieces of work into smaller pieces that can be understood and developed within the context of an individual sprint. The backlog of user stories is decomposed as needed so that, as a story gets closer to being accepted into a sprint and developed, the story becomes more and more granular.
  2. Backlog grooming the final step before a story is accepted into a sprint or drawn onto the Kanban board.  Grooming ensures that the story is ready for development (properly formed, sized correctly, understood and have acceptance criteria), and that a team can get started quickly.

The big picture defines the outside of the backlog onion.  However, after we peel the outside of the onion we can cut wedges directly to the core. Slicing wedges, like a minimum viable product, allows a team or teams to decompose and groom only the features and epics immediately needed.  Thereby getting the effort started quickly and effectively.   
Next, a simple example!