Scrum Decomposition Definitions - dummies

Scrum Decomposition Definitions

By Mark C. Layton

In looking at the process of decomposing your requirements into smaller and smaller pieces, the key is to do as little as possible. In fact, you should become an expert at doing the bare minimum, progressively elaborating requirements as the likelihood of bringing them into a sprint grows.

Gone are the days of spending endless hours working on defining and refining requirements that never see the light of day. The following figure depicts the different layers of requirement decomposition.

A visual representation of the decomposition levels.
A visual representation of the decomposition levels.

A requirement must earn the right of your investment. Only the highest priority items deserve your time in breaking them down into digestible requirements. Everything else can wait. This way, you’re always only working on the most important things. Don’t waste your time trying to boil the ocean.

The following terms relating to product roadmaps and product backlogs have been developed by scrum experts over the years. They aren’t scrum; rather they’re part of a collection of common practices that many of us use in the field:

  • Themes are logical groups of the features that you created in your product roadmap.

    If a feature is a new capability that a customer will have, a theme is the logical grouping of these features. The ability to purchase items from your website would be an example of a theme. Your product roadmap usually identifies and/or groups features as part of a theme.

  • Features are capabilities that your end customer will have that they didn’t have before.

    For example, purchasing items online via your mobile phone would be a feature. Your product roadmap usually consists of feature-level requirements.

  • Epics are the next stage in breaking down a feature into an actionable requirement.

    They are a series of actions related to the feature. The ability to purchase an item via your mobile phone from the shopping cart using a credit card would be an epic. It’s smaller than a feature (purchasing an item online), but yet it is bigger than the individual credit card integrations that singularly enable an item to be purchased. We don’t allow requirements larger than epics into a release plan.

  • User stories are the smallest forms of requirements that can still stand on their own. A user story consists of one action of value or one integration of value.

    For example, purchasing an item via your mobile phone from the shopping cart using a Visa card would be a user story. Purchasing an item using a MasterCard could be a different integration and thus a different user story. User stories are small enough to add to sprints and begin developing.

  • Tasks are the internal steps needed to implement the user story.

    During sprint planning, a user story is broken down into tasks. While requirements are things that the end user does, tasks are what the development team does to make the requirement work.

Each requirement goes through seven steps to fully build out its scope. At the end of these seven steps, you will know that each requirement works, can be integrated, and has been approved by the product owner. You are tangibly building products to showcase to stakeholders and thereby garner feedback. This feedback is then used to refine and create new requirements that make the product better reflect stakeholder needs, and the cycle is run again. You incrementally improve the product based on reality.

The seven steps for building each requirement are

  1. Requirement elaboration

  2. Design

  3. Development

  4. Comprehensive testing

  5. Integration

  6. Documentation

  7. Approval