It’s amazing how people somehow manage to figure out ways to abuse systems that they once so passionately fought to bring in. I recently came across a user story card which had the whole sequence diagram scribbled on it in an extremely small fonts. Interesting work-around, isn’t it? For those who have not seen one, a user story card is typically a 3×5 index card used by many organizations to represent a user story. The small size has been selected for a reason. The idea behind having a 3×5 index card is to constraint the user story to short and simple.
But user story card is just a part of the story. Let us try look at the whole story itself. Please allow me to tell you the story of user stories.
A user story describes desired functionality from the business perspective; it is the user’s story. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. I completely agree with Mike Cohn’s favourite Template for writing user story which are short and simple,
As a [user role]
I want [functionality]
So that [reason]
A user story is comprised of:
1. Card – the written description of the story, serves as and identification, reminder, and also helps in planning.
2. Conversation – this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.
3. Confirmation – the acceptance test criteria that the user will utilize to confirm that the story is completed.
A very good guideline for writing good user stories is the INVEST model
Independent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.
Negotiable – A user story is negotiable. The “Card” of the story is just a short description of the story which do not include details. The details are worked out during the “Conversation” phase. A “Card” with too much detail on it actually limits conversation with the customer.
Valuable – Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realizes that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.
Estimable – The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).
Small – A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.
Testable – A story needs to be testable for the “Confirmation” to take place. Remember, we do not develop what we cannot test. If you can’t test it then you will never know when you are done. An example of non-testable story: “software should be easy to use”.
So the moral of the story is this. User Stories being the cornerstones for Agile development, deserve their fair share of time, effort and most importantly prudence to be “invested” in them in order to lay a strong foundation for project.