Decomposing a Feature Into Stories

Featured resources

Related learning

Related blogs

Provide Feedback

The key to decomposing a feature into stories is understanding what a story is.

While a feature is a set of functionality at the program level, stories are individual functions that are small enough to be worked upon by a team, or sometimes, descriptions of the work to be done itself (also called “tasks”). Like other requirements, a story must also include acceptance criteria.

Features must be decomposed into stories for the teams to have something of a small-enough scope to work upon.

If a feature is very large, it may be helpful to create relatively large stories from it. These will still be implementable by a single team, but may require a complete iteration or even multiple iterations to develop.

An additional step will be required to decompose large team stories into a yet-smaller size, called “right-sized stories.” Right-sized stories can be implemented by one team in roughly three days.

The approach used to decompose a feature into stories is very similar to that used to decompose a capability into an MBI, except that unlike an MBI, neither the feature nor the story are a complete package of value. A feature covers functionality that is too limited to deliver value to the customer or stakeholder. So does a story. Both use the same format: Ideally the User-Story format, but in some cases other formats may be more useful (see Choosing Requirement Format).

Who does this practice

Who creates stories? It depends on the subject.

  • Business: Product Owners, with assistance from the Product Manager as well as the team members.
  • Architectural: For significant architectural functionality, the writer may be a System Architect. For less-significant functionality, the writer(s) might by team members with deep design understanding, such as a Technical Lead. Or a Product Owner. There are no hard-and-fast rules for who writes architectural stories, and writing them will likely require involving other architectural stakeholders such as Application Development Managers and Technology Owners.

What to do

Inputs

Inputs to this practice include:

  • A Feature to be decomposed, drawn from the Value Stream Backlog
  • Consultation and supporting information from the Product Manager and team members
  • Approach

Steps

  1. Choose the next Feature from the prioritized backlog.
  2. Obtain all written and verbal information about the Feature.
    • If the Feature has been developed in accordance with the article, Decomposing an MBI into Features, the Feature MBI will include supporting information about stakeholders, and other details, helpful for decomposition
    • If the Feature has not been thoroughly defined, work with the PM to gain greater insight into the Feature’s (and its parent MBI’s) stakeholders.
  3. Write the Story. This is normally done in User Story format, but consider other formats if needed. See Choosing Requirement Format
    • Attach to the Story any additional important supporting information you discovered while defining it
  4. Ensure that the Story, as you are defining it, is implementable in an optimal way. Edit the Feature to make it as implementable as possible, without adding implementation details.
    • Identify concerns such as implementablity with available technologies, expandability, modifiability, and dependencies and operability with systems.
    • Capture any bounds, limits or constraints to be levied on the implementation (e.g., performance).
  5. Develop Acceptance Criteria for the Story, consulting the Product Manager, Product Owner, and stakeholders as needed
  6. Continue with steps 3 to 5 until the whole Story and its parts satisfy the Product Owner and it is practical to implement

Template: Stories

The essential attributes of a story are:

  • ID. An identifier used to refer to the story.
  • Description. The intent of the story. It should be descriptive enough to allow a business analyst to write it several iterations after it was initially conceived. Here is a template:
    • As a <user>, I want <capability> so that I get <business value or functionality>
  • Size. Stories must be “right-sized” so that a teamlet can complete it within 1/3 to 1/2 of the iteration, ideally in one to several days.
  • Value. Can be expressed in “Business Value.”
  • Validation Strategy. Every story must have criteria so that the team can know, “Is this story done?”
  • Feature and Related Story. Where did the story come from and what else is it related to?
  • Story Captain. (optional / helpful) Add this to the card to indicate the team member responsible for shepherding the story to completion.

Types of stories

  • Business Capability Story. A capability of the Business that must be developed for the feature to be developed. This would involve such aspects as processes, documentation, training, or equipment.
  • Analysis Story. Research that needs to be done to describe the feature more fully, including studies, interviews, root cause analysis
  • User Story. How users interact with the feature, including requirements, test cases, high-level system design
  • Deployment Story. How the feature is introduced, supported, and marketed. Also known as a “Change Management” story. Includes the run book, configuration settings, environment specifications, application disaster recovery
  • Environment Story. Physical, logistical, or virtual configurations that must be established before the feature can be developed or deployed.

Tools and techniques

Tools and techniques that help with writing a Story include a word processor, spreadsheet, or graphic tools to express the chosen requirement format and to model the information being used to create the Story (relationships with other Stories in the Features, or between subsystems that cooperate in executing the Story, etc.).

Judging the maturity of a story

As you write a story, it is helpful to assess its maturity against a set of maturity criteria called INVEST:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Using these criteria, you can grade the story into one of three maturity levels; red, yellow, or green:

Red Level

  • Independent
    • Story is defined at a high level.
    • Story may be dependent on other stories.
  • Negotiable
    • Features may not be clearly defined. More clarification is needed prior to creating tasks.
    • Acceptance criteria may not be identified.
    • Prototypes/wireframes have not been started. Copy has not been provided.
  • Valuable
    • Story has not been approved by Product Owner (or stakeholders).
  • Estimable
    • Story Point estimation has not been done.
    • Impact to other IT teams is not understood.
    • All infrastructure/environment setup is not in place for the work to begin.
    • Developer or tester does not understand underlying code framework at high-level.
    • Team is not ready to commit.
  • Small
    • Story may not complete in an iteration.
  • Testable
    • User Story is not testable.

Yellow Level

  • Independent
    • Story is granular.
    • Story is independent of other stories.
  • Negotiable
    • Features are clearly defined. More clarification is needed prior to creating tasks.
    • Acceptance criteria may not be identified.
    • Prototypes/wireframes are in progress.
    • Copy has been provided but not signed-off.
  • Valuable
    • Story has not been approved by the Product Owner (or stakeholders).
  • Estimable
    • Story Point estimation has not been done.
    • Impact to other IT teams is understood.
    • All infrastructure/environment setup is not in place for the work to begin.
    • Developer or tester understands underlying code framework at high-level.
    • Team is not ready to commit.
  • Small
    • Story may not complete in an iteration.
  • Testable
    • User Story is not testable.

Green Level

  • Independent
    • Story is granular.
    • Story is independent of other stories.
  • Negotiable
    • Features are clearly defined. Easy to decompose story into tasks.
    • Acceptance criteria has been clearly identified.
    • Prototypes/wireframes are complete.
    • Copy has been provided and sign-off.
  • Valuable
    • Story has been approved by the product owner (or all business stakeholders).
  • Estimable
    • Story Point estimation has been done.
    • Impacts to other IT teams is understood.
    • All infrastructure/environment setup is in place for the work to begin.
    • Developer or tester understands underlying code framework at high-level.
    • Team is ready to commit.
  • Small
    • Stories can be completed in an iteration.
  • Testable
    • User Story is testable.

Example of story progression

Consider this high-level story (perhaps it is an MBI) as it grows in maturity during development:

  • Red Level Maturity. As an XYZ Bank credit card customer,
    • I want to log in and see my card account on my phone.
  • Yellow Level Maturity. As an XYZ Bank credit card customer,
    • I want to view my card balance on my phone. I can see my card balance using my smart phone.
  • Green Level Maturity. As an XYZ Bank credit card customer,
    • I want to be able to see my credit card balance updated real-time via my Android smartphone.
    • I can see my credit card balance.
    • My credit card balance is updated real-time within one minute of a transaction.

This illustrates the kinds of information that should be added to increase the maturity of a story. A more mature story is more likely to be implemented the way its stakeholders wanted. This, in turn, will make the development proceed more smoothly, with fewer rework cycles due to disappointing stakeholders and missing the point in the higher-level story from which the current story was being developed.

Outputs

This practice yields a Story that specifies

  • The contribution toward the Feature that the implementer of the Story must deliver
  • The bounds, limits and constraints to be levied on the implementation
  • The least-possible amount of design and implementation direction; leaving those decisions to be made “Just In Time” later

When to do this practice

After a Feature has been placed into the Value Stream Backlog, and approved for further development based on prioritization of the Value Stream Backlog.

Where to do this practice

This practice is not specific to any location.

Outcomes

Following this practice will provide the best-possible foundation for development:

  • Identifying stakeholders and describing their needs that will be served
  • Setting boundaries around the development effort, so it will achieve its goals without unnecessary gold-plating
  • Leaving as much room as possible for implementation decisions to be made by the developers