Skip to content
Browse
BABOK Guide
BABOK Guide

7. Techniques

7.18 Story Decomposition

Agile Extension to the BABOK® Guide

Story Decomposition is used to represent the requirements for a solution at the appropriate level of detail and are aligned to desired outcomes.

Story Decomposition provides a structure for defining the various elements of requirements at progressively smaller levels of granularity, starting with the broad system context and drilling down in multiple levels to eventually define the detailed acceptance criteria for individual stories.

Any story that is too large or insufficiently understood to elaborate, estimate, or deliver as a story is ready for decomposition. The most common agile approach to story decomposition can be described as “breadth-before-depth”:

  • the decomposition first describes a high-level view of what business goals need to be achieved,

  • the high-level view is decomposed into smaller components that provide increments of customer value (sometimes called minimal marketable features or MMFs), and

  • these smaller components are decomposed into stories, and the stories are elaborated into smaller increments with acceptance criteria (see 7.19. Story Elaboration).

Story Decomposition is undertaken progressively. In agile initiatives, the initial analysis activities identify the goals, MMFs, and most of the large stories. The initial decomposition of stories is completed incrementally. There is an implicit understanding that these stories are likely to change and that the understanding of the requirements will evolve over time. Therefore, decomposing to the lowest level of detail is likely to be a wasteful activity early in the initiative.

Figure 7.18.1: Story Decomposition

image.png

Story Decomposition is applied in different ways depending on context. For example, some business analysis practitioners follow the model linearly, as shown in the above diagram, while others use techniques that work best in their environment. Once the MMF or feature groups have been developed, use cases may be used instead of stories. Business analysis practitioners focus on dynamic collaboration, facilitation, and communication in getting acceptance for the minimum required detail to develop and deliver the solution.

.1 Solution Goals

The solution goals are the highest level of business requirements. They represent the business drivers for undertaking the initiative and form the rationale against which all of the detailed level needs are assessed.

.2 MMF/Component

Minimal marketable features are logical groupings of functionality and capabilities the delivered solution needs to provide to be worth releasing. Often these will form the themes for a single release and serve to provide a big picture context for the product being developed.

.3 Story

Represents a user story, job story, use case, or requirement to be implemented in the delivered solution.

.4 Acceptance Criteria

Conditions of satisfaction or criteria needed to validate a user story. Can be written as lists of items, specifications, or user acceptance tests (or a combination). Detailed requirements are represented and validated in the acceptance criteria.

.1 Strengths

  • Helps avoid the common problem of getting lost in the detail of the user stories and losing the big picture context.

  • It is important that team members keep the project's goals and objectives in mind and can trace implemented or requested functionality back to the driving business objectives.

  • Breaking the product into MMFs and epics helps with release-level planning, provides visibility into the development of the solution, and helps coordinate external program activities such as organizational change management and user training.

.2 Limitations

  • A common anti-pattern is the temptation to treat Story Decomposition as a way of reverting to detailed requirements upfront. Ensuring the continued emphasis on just-enough and just-in-time means knowing when to stop decomposing.

  • Story Decomposition should not be done based on process (step 1, 2, and 3 in a flow), architecture (build database, build server, build front-end), or procedure (design it, build it, test it). Rather, decomposition should be done based on customer valued features.