Title: User Stories Date: 2014-11-16 08:17 Author: eamonnfaherty Category: product Tags: agile, requirements Slug: user-stories
It may be hard to believe that in 2014 I still often get asked:
what is a user story?
I thought it might be beneficial to define it here so I can direct people to my blog for an answer and possibly a discussion instead of explaining several times (DRY principle).
To me, a user story is the smallest piece of business value that can be delivered as a piece of functionality. For example, an online room booking system for a hotel is not a user story as it comprises of many pieces of functionality; searching for rooms, checking availability, checking price, requesting the booking, seeing the booking status. Each of the pieces of functionality can be expressed as a user story following the three Cs framework from Ron Jeffries.
The three Cs framework encourages you to see user stories as:
Card - this is the summary of the user story. The card should be a reminder for a conversation and should follow the pattern:
As a USER I would like to DO SOMETHING so I CAN ACHIEVE SOMETHING
and should follow the INVEST principle:
- Conversation - this is the capturing of the discussions that occur or any special information that is needed to deliver the story. For example, when considering the searching for room availability there could be business rules that users can only perform 6 searches an hour etc. This is a way of specifying non functional requirements where a customer has been defined.
- Confirmation - this is the acceptance criteria describing what needs to be true before the story can be considered delivered. It should describe every possible combination of scenario so the story can delivered catering for the normal course and every possible alternative course - that is when things go to plan and when things do not. For example, when considering searching for room availability there should be acceptance criteria for when there are rooms available and when there are no rooms available.
Following these best practices should stand you in a very good position where it is clearly defined what is going to be delivered. It is easy to fall out of this practice but during planning you should ensure these criteria are met to ensure everyone knows why they are doing this work, what the work entails and when the work is complete.