User Stories and Agile Development – Part 1
I am reading a inspiring book “User Stories Applied: For Agile Software Development” by Mike Cohn (2004) which explains writing lengthy requirement specifications is a waist of time and how applying “User Stories” involves the client from start to end, keeps the communication standardised and balances the client/developer’s input to gathering requirements the same.
User roles
User roles are the type of user who will be using the application. Typically we write requirements based on a user, but we should brainstorm the type of users and consolidate them into different user roles.
For example, we are developing an Online Cemeteries Web Application that allows users to search where people are buried etc.
We can brainstorm the different types of users who potentially could use the web application:
- Genealogists
- Grand parents
- Family tree experts
- Younger generation
We consolidate them further
- Genealogists/Expert family history
- General Public
Finally we refine and came up with one user role as there will be no functionality to have a separate area of Genealogists in the system.
- User role: General Public
User Stories
Mike talks about the acronym INVEST
User stories should be:
- Independent
- Negotiable
- Valuable to Purchases or Users
- Estimable
- Small
- Testable
Typically user stories are written on cards with the front side having the story and any recorded “reminders” that summarise what developers have discussed with the client. The back side describes all the test cases that will meet the client’s expectations about the story. The more test cases are made before the code is written the better the developer can factor this into their code.
Here is an example from when we developed the Online Cemeteries Web Application:
Story: The general public can perform a simple search entering a first and last name which returns a list of results
Test Cases
- What happens when the general public enters no first name or last name?
- Can they enter 1 or none?
Story: The general public can perform a advanced search entering several parameters which results a list of results
Test Cases
- What happens when the general public enters no parameters?
Story: The general public can view an individual cemetery record which consists of several cemetery specific items
Story: The general public can go back and change their simple/advanced parameters to perform another search
Test Cases
- Does the system remember the general public’s input so that they can come back to the website and get the same results?
Tips – Here are some tips to building better user stories:
- If a story is too long and have too much detail, break the story down into smaller stories (keeping in mind they should run with the INVEST attributes).
- Don’t be technical! This is written from the client’s perspective!
- You can also write down non-functional stories!
- Try to not include any UI specific details as this can cause confusion later on during implementation
PART 2 will be on estimation and planning using “User Stories”.
1 Comment
Leave a Reply
You must be logged in to post a comment.
-
-
-
CodeLab Twitter- codelabnz: @possiblyb9 I now have blackberry for breakfast February 7, 2012
- codelabnz: I have now joined most ppl in indonesia and got myself a blackberry February 7, 2012
- codelabnz: From a bb February 6, 2012
- codelabnz: @bartekmarnane some info on micro orms http://t.co/UDfv5ML7 February 5, 2012
- codelabnz: @bartekmarnane depends on the project, but i found u have 2 be very careful with EF and the type of SQL it generates February 5, 2012
- codelabnz: @bartekmarnane I have been using EF for awhile, good for building apps quickly, but found it performs bad on higher traffic web applications February 5, 2012
- codelabnz: stuff it, I give up on Entity Framework, going to a micro ORM, back to writing SQL queries! I would rather do this than have a slow app! February 5, 2012
- codelabnz: Been too busy for tweeting lately January 21, 2012
- codelabnz: Blog Post: Setting the screen position when visiting previous page with jQuery http://t.co/evuKxVv0 January 17, 2012
- codelabnz: is anyone using Godaddy Cloud hosting? can someone provide their website so I could do a speed test? January 9, 2012
On the subject of user stories and tests I have a slightly different way of wording it (which comes from Behavior Driven Development (BDD)) and (although trivial) it may be useful to note it here:
As a Role
I want a Feature
To gain a Benefit
As a ‘Member of the General Public’
I want a search dialogue where I enter firstname and lastname
To get a list of matching burial records
By adopting this format we can always make a quick check that we have created the two vital ingredients (class of user, class of screen object) and that the benefit is actually listed in the requirements.
Recenly I have been looking at Gherkin and Cucumber as a way of writing the story and the tests…
Feature: Some terse yet descriptive text of what is desired
- In order to realize a named business value
- As an explicit system actor
- I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
- Given some precondition
- And some other precondition
- When some action by the actor
- And some other action
- And yet another action
- Then some testable outcome is achieved
- And something else we can check happens too
Feature: Search graves
- in order to find a grave
- as a Member of the General Public
- I want to see a list of names that match my input
Scenario: Search for graves by firstname and lastname
- given there are 125,000 graves
- and there are 16 that are an exact match to the input
- when a Member of the General Public
- enters a firstname and
- enters a lastname
- a list is displayed showing 16 graves
- and this matches exactly the records in the database
I don’t think it matters exactly how you write this stuff, what’s important is that the stories and tests are written in a way that can be understood by the customer, the developer, and the user for verification and validation before the code is written and the feature is integrated.