Agile in Practices - User Stories Explained
Reed_Fegg 120000A43D Visits (6799)
By Reedy Feggins, Agile Coach and WW IBM Solution Architect
This multi-part blog provides the reader practices for creating, planning and managing user stories to help steer your project towards a successful outcome. In this blog we explore what are user stories and how are they used. We look at examples of good user stories and bad user stories. In future posts we will drill in deeper into topics such as:
Part 1: Writing User Stories
Requirements serve many purposes, but essentially are used to capture and document the contract between the project sponsors and the development team on the exact deliverable. Usually these “business requirements” are large and vague and often must decomposed into smaller more specific specifications that are use to assist the development team with architecting, designing, coding and testing the system to ensure that it meets the original business need.
While traditional projects rely on several different types of requirements (features, use cases and system requirements to name a few), agile teams often capture stakeholder requests in the form of “Epics” and “User Stories” where the customer requests are expressed in the form of a short functionality description, told from the perspective of a user, that deliver value to the business.
Introduced several years ago as part of the Extreme method, User stories have become the primary method used by agile teams for estimating, planning and deliver value to their customers.
Use Story Example
A user story describes a small piece of system functionality, in a simple and easy to read sentence. A well written user story will describe what the desired functionality is, who it is for, and why it is useful. A well-written user story, using a format based on Mike Cohn book, User Stories Applied), would read:
User stories are often written on index cards or post-its to ensure only the essential details are captured about the stories. Once development team decides on the stories that will be developed in a sprint, it is further divided into tasks and resources are allocated accordingly.
Card, Conversation, Confirmation
To fully flesh out a user story, Ron Jeffries recommends that each User Story be described in his blo using “3 C’s” - Cards (Physical medium used by team), Conversation (discussion surrounding business needs) and Confirmation ( tests that verify them).
o The Card is the simple index card created and used for planning and prioritization purposes
o The Conversation represents the ongoing conversation, unfolding over time between the the team and members of the business. In most cases there is not one single conversation, it is an
o The Confirmation is the collection of acceptance tests captured during the conversations used to help confirm that the team has implemented the requirement properly. These acceptance tests often provide the detail of the story and much of the detailed documentation of the project.
Similar to user cases in that both are written in the form of scenarios, user stories are often much smaller in scope and more focused on delivering business value within a single iteration (usually 2 – 4 weeks in length. Use cases on the other hand usually contain multiple scenarios (basic flow, alternate flows, exception flows) that usually must be completed to deliver business value.
Ideally, stories should be created so that they can be completed by up to two team members in a week's time. If the team has a 2 week sprint will allow additional time as the story will typically also need to be packaged and tested further with other stories.Each story should be small and while it’s often difficult to start off with “small” user stories, its a good practice to groom your backlog to ensure you have properly sized stories containing stakeholder requests for a large amounts of new functionality. Large user stories are called “Epics” and are generally too large to be completed in one iteration (or sprint). Team can create Epics to represent stories that are not fully flushed out or pieces of functionality that must later be split into multiple smaller user stories before they can be scheduled for an iteration.
While anyone can write a user stories, it is the Product Owner's responsibility to ensure that the product backlog contains all the relevant users stories, contain sufficient details for the stories to be prioritize, estimated and ultimately ranked as part of a release or sprint planning session.
It’s essential for project to collect good stories that capture the business value requested by the Product Owner. INVEST is widely used approach for writing good user stories. When creating stories, it’s very important for a “team member” to play the role of “business analyst or tester” to make sure story conforms to the INVEST approach. The INVEST acronym stand for:
Independent Stories that are independent of each other are easier to plan. Dependent stories must be developed in a specific sequence so when backlog changes occur you must spend more time evaluating the impact on stories that depend on each other.
Negotiable User stories are not firm contract with the customer but rather they must act as a vehicle for providing clear understanding between everyone involved. Team must often negotiate with the Product Owner regarding which stories will be in a given iteration.
Estimable Team must be able to use stories to estimate effort and as stories are also negotiable, these estimates may change as the scope / effort is modified. But it must be possible to make a reasonable initial estimate so that the evaluation process can begin.
In practice, on successful agile teams, user stories can and often are written by Product Owners and the team members with help from the ScrumMaster (or Team Lead). While stories can be created at any point in the agile project, most teams conduct a story-writing workshop before or near the start of the project to create the initial product backlog. During this workshop, everyone participates in writing stories which are put into the product backlog.
The goal is to capture as many of the requirements (i.e., stories) that describe the functionality to be added over the next three- to six-month in the product backlog.Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog it
In the next posts we will drill in deeper into this topic focusing on some examples of creating user stories as well as capturing the stories in a Product Backlogs using a Rational Team Concert.