User Stories - How To

Developer
Dec 5, 2007 at 6:01 PM
Wanted to spin off a new discussions about user stories. I do like the template described by Behavioral Driven Development (BDD) at http://behaviour-driven.org/BDDProcess. When creating a user story you should follow this.

As a Role

I want Feature

So that Benefit

The role is the person who will benefit from the feature.

For example

Title: User Downlods Podcast Automatically from Subscribed Feed
As a User
I want to download podcasts from a feed automatically
So that when I come to my computer in the morning my favorite shows have already downloaded

According to BDD a story http://behaviour-driven.org/Story should have a Title, a Narrative and Acceptance Criteria which is a collection of scenarios to let us know when we are done.

Scenario: Valid Feed with Podcasts
Given That The RSS feed is valid and there are episodes to download, <plus other conditions>
Ensure That The feed is read and all episodes are downloaded, <plus other ways we can automatically validate that the user story is done>


Describing user stories is a difficult process. It will require iterations to break down stories into meaningful chunks. Of course we have as a starting point the functionality of Doppler 3. We should not feel that we have to implement everything that Doppler 3 does. Remember "less is more". The more features and functions a product has the greater the surface area. More surface area means more complexity, more potential for bugs, more things to document, more things for the user to understand. Our goal is to find the sweet spot of surface area where we produce a pod-catcher that has just enough surface area to meet the scenarios we want.


Coordinator
Dec 6, 2007 at 11:29 AM
From my experience working with Scrum (http://en.wikipedia.org/wiki/Scrum_(development) and XP http://www.extremeprogramming.org/ is that we have a product backloghttp://www.mountaingoatsoftware.com/product_backlog. This is the whole set of features that have been requested but not implemented or pulled into the iteration backloghttp://www.mountaingoatsoftware.com/sprint_backlog. The stories in the product backlog are light in detail, containing the sort of information that you have outlined, specifically attempting to avoid implementation details.

e.g.

As a Personal Shopper I want my Picking Device to give me the location of the item I need to pick next.
This will reduce the time that I spend searching for products.

Estimate : 4 days
Acceptance Criteria : Picking Device displays the correct picking location of the next product in the picking list

This would then be broken down into tasks as part of the iteration planning game http://www.mountaingoatsoftware.com/sprint_planning_meeting and estimations would be placed against the task using a form of planning poker http://www.planningpoker.com/.

e.g.

When creating the picking list XML include product location information when serializing the product.
Estimate : 2 hours
Acceptance Criteria : XML returned from GetPickingList webservice includes product location information.

This process helps to drive out assumptions and makes the entire team aware of any issues there might be with the implementation.

I found that this helps with ensuring that everyone is comfortable with the estimations and ensures that the customer is aware of what is being implemented and when.
Before we had the planning poker and two levels of estimates, Story level and Task level, I found that experts in an area would be asked about how to implement the User Story and give estimates for what they thought the tasks might be. This lead to people who were not experts in that area feeling like they were under pressure to complete the task in the time that the expert had estimated.

I am not sure if we could follow this exactly for Doppler, but I think that we should have these goals in mind.