A User Story is intended to be a method of communicating business or application requirements between potentially nontechnical customers, team members who are not developers and the development / operations teams that must implement the required application or features. In other words, the User Story needs to be understood by all but still provide enough detail to allow the technical teams to actually understand the requirements and build the solution. So what makes a good User Story? A User Story should be a concise description of a piece of functionality that will be valuable to a user or owner of the software. To put it another way a User Story is a more universal way of writing a software requirement or deliverable.
A good User Story should describe [Who] the user of the feature is, [What] they need to do and [Why] they need to do it. User Stories typically follow the format below:
As a [Who]
I need [What]
So that [Why]
or we could say
As a [Type of User]
I need to [Perform some action]
So that [business value received]
Following the INVEST acronym User Stories should have the following characteristics:
[I]ndependent Should not depend on any other User Story to be considered complete
[N]egotiable The delivery team needs to discuss User Stories before committing them to the “sprint” backlog. This discussion should happen during the sprint planning meeting
[V]aluable The completed User Story should add value for the customer. Customer should understand the resource and time cost associated with a given User Story based on Story Points estimated by the Product Owner and confirmed by the delivery team. This will help the customer and Product Owner decide if the value of the User Story is worth the cost in time and resources and prioritize the User Story accordingly
[E]stimable The User Story should be specific and granular enough that it can be completed within a single sprint. If the User Story is so complex that it cannot be completed within a sprint, then it is an Epic or Feature and should be broken down into small components / User Stories before being added to the backlog. See this post on Story Point Estimation
[S]mall User Stories should be small enough that the specifics of the implementation of the User Story should not take more than 10 Developer (or Delivery Team) Tasks to flesh out
[T]estable The story should have Acceptance Criteria that describes what is required to consider the story complete. These Acceptance Criteria should present a clear path to testing requirements
Below is what seems to be a relatively simple example of a User Story
As a User
I need to register
So that I can manage my account
While the previous User Story seems pretty straight forward at first glance, as we analyze User Stories we may find that we have very large and complex Epics masquerading as User Stories. In these cases it will be necessary to properly size or “Slice” the User Story or Epic into smaller chunks that can be completed in a single sprint. See the Slicing User Stories 7 Methods Blog Series for more details. I wouldn’t go as far as to say the previous User Story is Epic in nature but it could use a little clarification. For example what exactly does account management entail? What constitutes valid registration information? We can break the story down to be a little bit more specific without getting technical.
As a new user
I need to register with my Facebook account
so that I can access members only content
As a new user
I need to register with my Google+ account
so that I can access members only content
As a new user
I need to register with my Email Address and Password
so that I can access members only content
As a new user
I need to add my address to my Profile
so that I don’t have to re enter it for every order
By breaking the story down we ensure that the tasks necessary to get the story to the Done will take less than the length of the Sprint. We have describe the [What] in enough detail that the implementation team can complete the work without telling them [How] to do their jobs.
The [How] or the “technical details” are captured in tasks [Work Items] linked to a User Story in a Project Management / Work Item Tracking tool such as Jira or Team Foundation Services. Delivery Team task / technical details should be capture as specific tasks that can be completed in 2 hours or less. In a Continuous Integration environment as these tasks are checked into Source Control a build trigger would cause an automated build and automated test run. If any of the automated tests fail the system can automatically log a Defect and assign it back to the developer checking the code into source control. This rapid feedback keeps technical debt from slipping down the delivery pipeline.
Common User Story Issues
User Stories are too formal or contain too much detail – Keep the story simple and to the point. The detail should be fleshed out in tasks linked to the User Story during Sprint Planning
Technical tasks masquerading as stories Remember User Stories should be understood by the customer and the user as well as all non-technical stakeholders. Technical details are for the nested developer tasks.
The conversation is skipped – The team should evaluate User Stories provided by the Product Owner from the Customer in their Sprint Planning meeting. This is a good opportunity to play Planning Poker and make sure all team members are in agreement about the size and complexity of the User Stories planned for the coming sprint.
So remember keep User Stories simple and to the point, work out the details in the nested Delivery Team Tasks and be sure the team discusses User Story complexity, Story Points and Acceptance Criteria during Sprint Planning before committing the User Story to the Sprint Backlog.
Happy storytelling…
For more details on User Stories and estimating story points see the Story Points Estimation post
