User Stories are the bridge between the customer and the development team. They are short, clear, written sentences which tell everyone what the system needs to do for the user.
For the Agile practitioners, the user stories are known as one of the primary development artifacts for Scrum project teams. Those artifacts resume clearly the requirements so that the development team can do the appropriate estimation of the time and effort to implement it.
Example of user story from Wikipedia:
As a user closing the application,
I want to be prompted to save anything that has changed since the last save
so that I can preserve useful work and discard erroneous work.
Estimate:7
Priority:4
Written by the customers, the user stories have the followings characteristics:
- Usually, there is a pattern used for written the user stories: “As a <role>, I want <goal/desire> so that <benefit>”
- They are sentences readable in a few minutes
- Functional and non-functional requirements could be transcript in user stories
- They are estimated – the development team estimates how long the stories might take to be implemented. Each story could be have an estimation of 1, 2 or 3 weeks, in “ideal development time”. This ideal development time is the length of the time working with no distractions or other assignements.
- The user story estimated to more than 3 weeks – they are called epics – need to be broken down further. Those estimated to less than 1 week could be combined because they are at a too detailed level.
- They are prioritised – the customer priorities the user story with a High/Medium/Low criteria or 1-10 numbers. This prioritisation could be changed at some point, depending on the customer needs. Epics have lower priority because they include more smaller user stories.
- They focus on their needs and benefits not on specific GUI layout, algorithm, technology, database, etc.
- They provide enough details to make a reasonably low risk estimate of how long the story will take to implement. Detailed description of the requirement will be asked to the customer when the developers need to.
- They drive creation of acceptance tests
Well-written user stories follow a set of criteria called INVEST:
- We can be able to move stories around. Those stories which are dependent have to be combined and form an Independent (I) one.
- User stories could be rewrited, discarded, changed. They are Negociable (N).
- In order to deliver continually valuable software, stories focus on the end-user (stakeholders), bringing them value. They are Valuable (V).
- Part of an iteration, the user story must have a size for the working effort. User stories are Estimable (E).
- User stories have to be small enough to be implemented within a sprint (2-4 weeks). Thus, they are Size appropriately or Small (S).
- As long as the user stories are DONE (tested), it means that the acceptance criteria were passed. They are Testable (T).
Are you trying to implement user stories? What challenges do you face? Let us know in the comments!
If you want to better understand and estimate the user stories, we can help with:
- Learn more about solving the right problems for your customers at the Acceptance Test Driven Development with Markus Gärtner
- Learn more about user stories at the User Stories for Agile Requirements, also available in-company
Want to learn something else? Let me know and we will create a customized package for your needs.
