In an agile organization, the User Story replaces traditional requirement documentation. While traditional requirements like functional or user interface specifications try to be as detailed as possible, User Stories break down the business requirements into the smallest piece of business value that a development team can deliver within an iteration.
That said, there is an art to writing effective user stories and UX designers cannot simply rename their User Interface Specifications to User Stories. Use the following guidelines to consistently deliver requirements that can be easily understood by your development teams.
Choose the right amount of detail
The size of the user story should be small enough to code and test within an iteration. The size of the story determines its classification within Agile (Initiative > Feature > User Story)
- Initiatives are large stories – too large to develop and test within an iteration
- Features are smaller stories within an Initiatives – still too large for an iteration
- User Stories are the smallest chunk of work that can get completed within an iteration
Effective user stories should follow the INVEST acronym championed by Bill Wake a leader in the agile arena.
Follow a consistent format
When writing user stories use the template below to guide the story in a way that’s easily understandable and consistent across development teams.
Focus on what makes a user story effective
- Define development team efforts in terms of business value
- Prevent the business from introducing too much detail too early which can lock the development team into one solution and prevents the exploration of alternate options
- Avoid the appearance of false completeness and clarity
- Are small enough to invite negotiation and movement in the backlog
- Leave the technical functions to the architect, developers, testers, and so on
- Writing Good User Stories – All About Agile
- User Stories – Agile Alliance
- Agile User Stories – Scrum Alliance
- Write a Great User Story – Rally Help