PMI Sites
Register
Disciplined Agile
Search

    Practice: Decomposing a Feature into User Stories

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

    While a feature is a set of functionalities at the program level, user stories describe individual functions that are small enough to be implemented by the team. Besides the story narrative, a user story also includes acceptance criteria.

    Features must be decomposed into user stories for the teams to have something of a small enough scope to implement. If a feature is very large it may be helpful to decompose it into coarse-grained stories, sometimes called ‘epics’. These will still be implementable by a single team but may require several iterations to complete.

    With epics an additional step is required to decompose them into smaller “right-sized” user stories. As a rule-of-thumb, right-sized user stories can be implemented by a team in three days or less.

    The approach used to decompose a feature into user stories is very similar to that used to decompose a capability into an MBI, except that unlike an MBI, neither the feature nor the user story represents a complete package of value; they cover functionality that is too limited to deliver value to the customer or stakeholder.

    Who Does This Practice

    Who creates user stories? Since user stories represent desired functionality from a user’s perspective, it is somebody with domain expertise and insight, typically the product owner or subject matter expert.

    It is important to note that user stories are requirements, not technical specifications, and should be void of any technical or implementation details. 

    What to Do

    Inputs

    Inputs to this practice include:

    • A feature to be decomposed
    • Any supporting information from the product manager and team members

    Approach

    1. Obtain all written and verbal information about the feature.

    • Well-defined features include supporting information about stakeholders, and other details, helpful for decomposition.
    • If the feature has not been thoroughly defined, work needs to be done to gain greater insight into the feature’s stakeholders and their needs.

    2. Identify user stories within the feature by asking questions like: Who will use the feature? Why would they use the feature? Try to come up with as small segments of functionality as possible (see splitting user stories below.)

    3. For each identified user story, write a sentence or two about the user’s goal with the story. This is normally done in the user story format below, but consider other formats as needed.

    4. As a user story is getting closer to implementation, refine its details to a point where it can be understood and discussed within the team, by

    • Adding more descriptive details
    • Adding acceptance criteria, consulting the product owner and stakeholders as needed.

    5. Ensure that the story, as you are defining it, satisfies the INVEST principle (see INVEST below).

    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: User 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 common template:          As a <user>, I want <capability> so that I get <business value or functionality>
    • Any additional narrative that explains the story.
    • Estimate. Stories must be “right-sized” so that the team can complete it within 1/3 to 1/2 of the iteration, ideally in one to a few days. (Estimates are determined by the team, not by the product owner).
    • Acceptance criteria. Every story must have criteria so that the team can know when a story is complete.
    • Feature. Statement about where the story come from.

    Types of Stories

    User stories describe desired functionality from a user’s perspective. In general, the user is somebody easily identifiable and who will be using the functionality as they are interacting with the business through a user interface such as a tablet, smart phone or regular computer.

    But what if the user is not that easily identified? There’s always a user – otherwise there wouldn’t be a need – so it becomes a question of understanding who the user is and their need (conversely, if there is no discernable need, it is probably not a viable story).

    For example, a team that is in charge of developing a service API for authentication services may identify other headless services as their users, and hence they formulate their user stories from those other services’ perspective.

    Caution: While it may be tempting to use “story” as moniker for any and all types of requirements, and perhaps even just tasks in general, using it for things other than user requirements is confusing and should be avoided. Other types of requirements exist besides user stories and the appropriate format shall be used for each type of requirement.

    INVEST: Judging the Quality of a Story

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

    Independent. Each user story shall be able to be implemented and deployed independently of other user stories.

    Negotiable. Keeping the user story narrative free from implementation details leaves room for “negotiation” between the product owner and the team.

    Valuable. The user story must articulate the actual value that the user is looking to achieve.

    Estimable. Is the user story clearly described and complete enough so that the team can reasonably estimate it?

    Small. Is the user story small enough to be implemented in three days of effort or less?

    Testable. Does the user story have defined acceptance criteria, and do they cover all aspects of the user story?

    About User Story Estimates

    A common practice is to estimate user stories using a ‘story points’ system, which supports relative estimation. Estimates help understand the overall capacity of the team (called ‘velocity’) as future iterations can be planned based on learnings from past iterations. For example, if a team finished an average of 42 story points over the past few iterations, it can be assumed that they will be able to finish 42 story points in the next iteration.

    It is the team that is doing the estimation, and it is normally done as a group activity to make sure that all aspects of the user story are taken into consideration.

    Splitting User Stories

    User stories are decomposed using a technique called “story splitting.” Using this technique, a single story is split into two or more smaller, or narrower, stories. The resulting stories should still satisfy the INVEST criteria and provide user value when implemented.

    From a technical implementation viewpoint, stories should always be split “vertically” through the technology stack – not horizontally. Each resulting story still implements user functionality and can still be deployed independently of the other stories.

    Tools and Techniques

    When first introduced, user stories were captured on index cards and managed on a physical task board. This format helped enforce their light-weight nature, and the idea of them being “an invitation to a discussion to be held” (between product owner and team): the story narrative was captured on the front of the card; and acceptance criteria on the back.

    Nowadays, tools and techniques that help with writing stories include word processor, spreadsheet, or graphic tools to express the chosen requirement format and to model the information being used to create the story.

    Outputs

    This practice yields user stories that

    • Are small enough to be implemented in less than three days of effort.
    • Are of good quality and satisfy the INVEST principle.
    • Are ready to be implemented.

    When to Do This Practice

    This practice occurs over a longer period of time, starting when a feature is split into constituent user stories during backlog refinement activities, and then individual user stories are refined and completed as they are being prepared for implementation.

    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 

    Product Owner Overview