Jump to content

Agile Software Engineering Cheatsheets/Printable version

From Wikibooks, open books for an open world


Agile Software Engineering Cheatsheets

The current, editable version of this book is available in Wikibooks, the open-content textbooks collection, at
https://en.wikibooks.org/wiki/Agile_Software_Engineering_Cheatsheets

Permission is granted to copy, distribute, and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 3.0 License.

Agile Requirements - User Stories & beyond

User Stories Cheat Sheet

User Story Definition

[edit | edit source]

A User Story represents a small slice of requirement which benefits the user or customer.

A story can be defined like this:

  • Card: As a user I want to function so that benefit
  • Conversation: Captures details relevant to the implementation of the story, such as the tradeoffs we are making
  • Confirmation: (aka Acceptance Criteria) - What would I check to make sure the story is Done

INVEST

[edit | edit source]

A good story should be:

  • Independent... of other stories so it can be prioritized solely by value, cost and risk
  • Negotiable... so the team and Product Owner can discuss tradeoffs
  • Valuable... to the users, so value can be the primary consideration in prioritizing, and so we are clear on why we are doing this
  • Estimate-able... so we can better assess the return-on-investment, plan & predict, and make sure we really understand it. A Spike may be need to to estimate a story with a high uncertainty due to technical challenges or lack of knowledge
  • Small... so it can flow quickly through our pipeline, with as few surprises as possible, and so it can be elaborated and discussed at the right resolution
  • Testable... so we have a good way to know when we are done

Valuable Stories

[edit | edit source]

There are different ways user stories can provide value:

  1. User value - The best value possible - The user story increases the value of our product from the user’s perspective
  2. Feedback from users (e.g. demo or mockup to users)
  3. Feedback from PM
  4. Remove technical uncertainty
  5. Remove schedule uncertainty - Finishing this story gets us closer to our goal
  6. Enables us to deliver faster (e.g. refactor the database schema, invest in continuous integration...) - This is the worse type of value as users would prefer not to pay for this, and cannot provide an indication of priority relative to other user stories. These are not really user stories but rather engineering work items, and are best handled continuously alongside user stories, but when they accumulate and need to be managed, a portion of the team’s attention and effort will need to be allocated to these types of items

Beyond User Stories: Epics, Themes, MMFs

[edit | edit source]

While stories are the basic unit of requirement, a higher-level view is usually needed, and may include:

  • Theme (a broad category of stories, such as monetization, mobile, SEO...)
  • Epic - A large story representing a feature-level item, which is broken down into multiple user stories
  • MMFs - Minimally Marketable Features which represent the minimum subset of stories in an epic which can be released and marketed to users. This level of requirements often is often managed and visualized at the enterprise level akin to the way user stories are managed by delivery teams. Note that an MMF may include Epics and/or vice-versa.

A product’s first MMF is the MVP - The Minimum Viable Product

Minimally Marketable Features (MMFs) typically contain multiple User Stories. User Stories might be tracked at the team level, while MMFs are tracked at the enterprise/line-of-business/product-line level.
Related User Stories can be bundled into themes. Minimally Marketable Features represent the minimal set of User Stories which can be marketed on their own

The Backlog

[edit | edit source]

Stories are kept in a single, prioritized backlog, which represents user stories we will probably start working on soon. As we get closer to working on the stories, we groom them, breaking them down and fleshing them out, so the delivery teams can pull them in.

Story Grooming

[edit | edit source]

Story Grooming is the process of preparing stories to the point where they ready to be worked on by a delivery team. This is done continuously, so that stories are defined just-in-time, and so we don’t get into a situation where the team does not have enough work. Teams typically schedule one-hour meetings twice a week to groom stories. Product Owner, Developers, Testers, User experience designers, DB Admins... all take part in story grooming.

Definition of Done - DoD

[edit | edit source]

Represents what the team commits to do for every story before it can be considered “Done”. It should include as much the team can reasonably do, and will minimize the waste incurred with items that are completed but not ready for release.

Example of a Definition of Done:

  • All acceptance criteria passing
  • Checked into the main branch
  • Tested as per test plan
  • Demo’d to PM
  • Increases unit tests coverage
  • Code review + implement all identified changes required
  • All bugs fixed and verified
  • Added to release notes

This should be created, used, and maintained by the team, and is team-specific.

Personas

[edit | edit source]

Personas are fictional characters created to represent the different user types within a targeted demographic, attitude and/or behavior set that might use a site, brand or product in a similar way. Using personas while defining a story can help the team focus on the need of specific users, instead of developing generic features which won’t be great for everyone. They also help us focus on a subset of the users, so we can get feedback earlier and develop products more gradually.

Vertical Slices

[edit | edit source]

Ideally, user stories represent thin slices which cut through all necessary architectural layers of the product. This way we can get the end-to-end feedback and have more chance of getting real value.

Definition of Ready - DoR

[edit | edit source]

Teams often use a checklist which represents what we commonly want to consider before we are ready to pull the story into our pipeline. DoR can include things like:

  • Performance
  • Scalability
  • Supportability (log entries, monitoring & troubleshooting)
  • Deployment (upgrade & rollback, any changes to the )
  • Compatibility (backward & forward compatibility with other systems and services)
  • Dependencies to other systems/teams

While not all items will apply to all stories, these are things we want to ask ourselves before we start working on a story so we minimize the change of omitting an important aspect of the story.

Tasks

[edit | edit source]

Stories are sometimes broken down into tasks which are undertaken by individual members of the delivery team. Tasks are typically very small (less than half a day). Breaking down into tasks will often surface some questions about the requirements and the design of the user story.

Possible ways to break down stories

[edit | edit source]

You can use the following patterns to break down stories:

  • Break Workflow/Sequence into individual steps
  • Simple before complex (UI, Logic, Formatting...)
  • Manual before automatic
  • Defer performance and scalability
  • Subset of the data
  • See links for more information on patterns
  • Techniques for Breaking Down Epics to User Stories
  • These include Story Mapping and Value Stream Analysis, among others.
  • Story Mapping - This technique works best for epics which include a flow of work. The various activities which compose the epic are laid out in a linear sequence and fleshed out into user stories, listed by criticality.

Impact Mapping

[edit | edit source]

Another technique which can work well for the big picture, before we get down to the individual flow level is Impact Mapping, in the goal is broken down into players/stakeholders, then how, and then what. A highly simplified example might look like this:

More Information

[edit | edit source]