In Agile, we avoid exhaustive documentation with a little thing called user stories. While user stories themselves may seem short and unimpressive, their effect on how teams work is profound. Without the task of comprehensive documentation, teams are empowered to do their most impactful work faster than ever.
While it may be difficult for those used to creating comprehensive documentation to shift to writing brief user stories, it’s a crucial point of adaptation if you want to truly be Agile. Remember, ‘working software‘ is always more important than ‘comprehensive documentation,’ according to the Manifesto.
Creating user stories
User stories are quite simple to construct. All you need is a description of a feature or requirement of a project. They can be written out on sticky notes, index cards, or the digital program of your choice.
They are generally written from the perspective of the user. A simple format to follow would be:
- As a < type of user or role >, I want < goal > so that < reason >.
This answers three basic questions: who what, and why. Without all three, the team will not be able to deliver a proper solution.
For logistical purposes, also include:
- A title and/or ID for the story
- Acceptance criteria (i.e. “I am done when…”)
- Estimate points
- Category (i.e. payments, account, etc.)
All of the above info should be written out on your card. However, stories are not simply documents; they are conversations. Stories are to be written in-person by the team and facilitated by the Product Owner.
Making great user stories
There are a few other considerations you should have when creating a user story. As you refine the details, you can follow the INVEST model, which means each story should be:
Independent: Reduce dependencies as much as you can to make things easier to plan.
Negotiable: The end result should be a collaboration between team members and the Product Owner.
Valuable: Each story must provide value to the customer and business.
Estimable: The better estimate you can provide, the easier it will be to split among team members.
Small enough: Each story should be able to be completed in less than a week by the team.
Testable: Your acceptance criteria should properly validate the story when all tasks are complete.
Here’s an example of a proper user story:
As a user, I want to be able to add a comment to an issue, so that I can give feedback and important information to the team.
The user needs to enter text into the comment field.
If the user clicks “Save,” then the data should appear in the comments section of the issue.
If the user clicks “Cancel,” the data entered is refreshed and the fields are cleared.
The more user stories your team creates together, they better they will get at defining their story and acceptance criteria. The more the team works together, the better they will get at estimating work and delivering that work on time. As with anything, practice is the key to making user stories an asset to your team’s workflow.