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

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

CCC edit

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

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

There are different ways user stories can provide value:

User value - The best value possible - The user story increases the value of our product from the user’s perspective
Feedback from users (e.g. demo or mockup to users)
Feedback from PM
Remove technical uncertainty
Remove schedule uncertainty - Finishing this story gets us closer to our goal
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

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

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

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

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

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

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

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

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

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

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:

Agile Software Engineering Cheatsheets/Printable version

Contents