How to write user stories

Recently came across a 20 page long requirements document and didn't know where to start and what to remember, specially for somebody like me who has a memory of a goldfish. I stopped using those time consuming, long and boring requirements document way back in 2007 and started use cases and then moved to user stories. They are easy to write and understand and best thing about them is "collaboration". I personally love those user story writing workshops with loads of index cards, post-its, marker and DONUTS. So how do you write user stories?

Behaviour driven development - an example of BDD user story

According to Mike Cohn User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Title: One line describing the story
Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
Scenario 2: ...

Here is an example from my recent project at Toyota motors.

ProductOwnerScenario 2:Scenario 3:

Sales Performance Report

Narrative:
As a [Sales Analyst]
I want [to see parts sales figures for the current month(mtd)]
So that [I can track sales progress against monthly target]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: BI User login
Given [I am logging in as a BI user]
And [some more context]...
When  [the log in successful]
Then  [I will be taken to sales performance report]
And [I will be able to select month and date or defaults to current month and date]
Hope this helps! Good luck with user story writing and don't forget to buy donuts (skinny ones for me please!).

Is there a point in story point estimation? How do we estimate accurately?

This is a relative size of the story compared to other story estimated by the same team – it has nothing to do with who is implementing it and how long it's going to take. Story points are relative estimate, so that you know that 5 point story will take approx. 5 times longer than 1 point story.
 
Benefits are
-          Team’s velocity can be measured

-          Allows team to plan future sprint without over/under committing and forecasting total number of sprints. As a result no unrealistic expectations are placed on the team

-          Helps team to focus on completing dev and testing in the same sprint

-          Helps teams reach a sustainable pace and due to this the business starts to believe in the team


Hours (or ideal hours) are more about time estimation. It can lead to several problems:

- Your "hours" are not the same as mine. It can be harder to make team estimate during release planning.

- It’s easier to make relative estimates and then calculate team velocity in points.

- Stories are usually decomposed to tasks for the sprint. These tasks can be implemented by different people. So total effort is not simply calculated as sum of task estimates.
Usually it's recommended to make story estimation in points for release backlogs and in hours for sprint backlog.

1. Story points are a pure measure of size and complexity
2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
5. Story points don’t influence behaviour (e.g. Parkinson’s Law)
6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.
 
Have fun