User Stories
What is a user story?
A user story is one or more sentences describing what a end user needs. It is expressed in everyday language or the business language of the user. A user story is NOT intended to capture ALL knowledge required to implement a given feature. User stories facilitate conversations between customer and developer. The details required to implement the story are acquired overtime via these conversations.
Why user stories?
- Verbal communication – yields greater knowledge and understanding
- Comprehensible (non technical)
- Right size for planning
- Work well with iterative development
- Encourage deferring detail
- Opportunistic development
- Participatory design (between developers and customer)
- Build up tacit knowledge
Structure of a User Story
As a {user role} I want to {do something} so that {reason}
- User Role = Who
- Do Something = What
- Reason = Why
NOTE: we are not talking about HOW to implement it.
The structure of the sentence forces us to talk about requirements and NOT design. This prevents us from short-circuiting the analysis and design phases.
Attributes of a good user story
Very good blog explaining the important attributes of a user story
http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest
Just think of INVEST to remind you of the attributes of good user story.
- Independent – loose coupling between user stories. Makes planning much easier.
- Negotiable – don’t design a solution or specify so many details that you paint yourself into a corner. We should always be free to change our mind on HOW to implement the given requirement at a later time.
- Valuable – must be a value to the end user
- Estimable – must be able to put an estimated number of hours or days
- Small – less than a week
- Testable – so we know when we are done.
A useful tool for ensuring that user stories adhere to INVEST is to either break a user story apart into smaller user stories. Occasionally, the opposite might be true (combine many smaller use stories), especially in support of Independent.
Drawbacks to User Stories
- Difficult to understand relationship between stories
- May require augmenting them with additional documentation if traceability is a mandate
- May not scale well to large teams (too much conversation and too many pathways)
Guidelines for Good Stories
- Start with Goal Stories – why is user using the system?
- Slice the Cake – slice up large stories in way that the user can actually accomplish something (not part of something). e.g. 1) collect data 2) write to database. That is bad. Good would be to 1) collect basic information, 2) collect detailed information
- Write closed stories – don’t write a story that will never complete. e.g. A user can manage his projects. instead, breakup into smaller chunks that can be completed. e.g. A user can add and remove team members from a project.
- Put constraints on cards
- Size the story to the horizon – stories you are going to tackle sooner need more precision. Stories far in the future don’t need same level of precision.
- Keep the UI out as long as possible – that’s a design task, not a requirements task
- Some things aren’t stories – if it does not fit in a user story, use a different method. Use this is a last resort, not as a cop out to learning how to write good user stories.
- Include user roles in stories
- Write for one user
- Write in active voice
- Customer writes – ideally, but requires training and discipline on the part of the customer
- Don’t number story cards – tempting, but pointless overhead. Short title is better.
- Don’t forget the purpose – to remind you to discuss the feature
Final Thoughts
User stories are a TOOL. They are a great tool that every software developer should master. But like any tool, it can be misused and thus not yield the desired results. Also, like any tool, it is not appropriate for every job. Before you try to use this tool, I highly recommend reading some books, reading blogs of those who have had success, and start small.
Books
