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.
User stories should have the following characteristics:
- Should not depend on any other User Story to be considered complete
- The delivery team needs to discuss user stories before committing them to the "sprint" backlog. This discussion should happen during the sprint planning meeting
- 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
- 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
- User stories should be small enough that the specifics of the implementation of the user story should not take more than 10 developer tasks to flesh out
- 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
Technical details are captured in tasks 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 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 not technical stake holders. 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 developer tasks and be sure the team discusses user story complexity, story points and acceptance criteria during sprint planning before committing the story to the sprint backlog.
Happy story telling…
For more details on User Stories and estimating story points see the Story Points Estimation post