User stories

Firstly I must say that if you haven’t read User Stories Applied then you must. But to synthesize: A user story is a task that adds business value. Perhaps it might be easier to have a context for us to discuss around. Lets imagine this context to be a shop that wants to go online. With this we can create a backlog, user stories, perform estimates, planning and everything that goes with releasing a product.

Here is the fiction:
The owner of the local flower-shop is tired of taking orders over the phone. Hard of hearing he gets it wrong more often than not. The neighborhood is transforming itself into tech-savvy people who use the internet for everything. He decides to take his business online. Sadly you are asked to ensure this happens. This is some of the information you gathered:
Ability to add products – some products are just a numeric variance like 3 roses and 12 roses
Ability to price products – he prefers to price them high
Coupons for occasions – this is mostly to bring the prices back to parity
Sell products online – of course
Periodic sales reports – show me the money
Place orders for phone orders – for those lay people who hate the internet
Keep a customer database – regularly spam them with information

How do these requirements now fit into an iterative development cycle. We obviously need to break the requirements down. How do we go about it? Lets start at the highest level:
Jeff, the bookstore owner, would like a website that allows him to sell his books.
This requirement needs to be broken down. One approach is to think about it in terms of the flow that occurs typically for that business. Lets try to break this down:

Here we have tried to track the path a product takes right from Jeff adding it to the catalog to it being shipped to the customer. Of course this system can be as complex as we want to make it but lets limit the scope to the above set of stories. We could make this elaborate and have stories for users registering, inventory notification, catalog structure, taxonomy of the products, various prices (Sale, Clearance etc) and so on. This probably helps with the domain and less so with User Stories.

Epics
We could argue that the 8 stories above are not really stories but Epics. It is quite a natural process to start breaking requirements down to Epics and then get to a story level. A story has to be completed with an iteration – whose length varies from team to team. I have typically used 2 weeks for most of my career. Most of the stories in the table above are Epics.
Prioritizing Stories
There are many considerations we need to make when prioritizing stories. The primary one is business value. For Jeff he might be able to live without a few of the stories but you could argue that the customer purchasing a product is what the site exists for. Jeff might say that he will notify the customer himself, shipping the product can be manual, or can we add the product from the list page instead of an additional page in the form of  a detail page?
Technical Tasks
There are secondary considerations too. Its fairly common practice to start with an Iteration 0 where the developers perform a bunch of technical and setup tasks that allow the project to be kicked off. There will be other times too when we see technical tasks that have to be worked on either to remove technical debt or do some work that doesn’t provide direct business value. In my experience its impossible to avoid technical tasks. What is important though is to explain the nature of the task to Jeff and ensure that he is convinced of the reason for the priority.

Spikes
The third consideration are spikes. Spikes are time bound stories that provides insight into the amount of work a story will take. We could dilute the purchase story to take only paypal payments. You ask the team for an estimate and no-one has done a paypal integration before. You then take a one day spike to make this determination. Note that this needs to be time-bound and not necessary limited to 1 day. The reason to make it time-bound is so that we don’t get lost in its work. We just need to learn enough to be able to estimate the purchase story.

Look at the new list now. We have Iteration 0 stories. We have determined that we need to be able to sell the products as soon as possible. Now we need to think about splitting stories. Can a pair of developers create a page with a list of products in an iteration. Possibly but you might have to negotiate. You might have to split this story and take out some of the complexity. For example:
The approach here is to talk to Jeff and make List of books and the manual population of the database a priority. That way a user can see a list of books without images but perhaps with sufficient information for a user to be interested in making a purchase. Of course Jeff could say No but then we would probably still split the stories like this even if it doesn’t end up in Production.

Acceptance Criteria
The approach I take to writing the Acceptance Criteria is to think about it in the form of Jeff testing the story by following a series of steps. For example:
As a customer, the user is able to see a list of available books for sale
I would write:
Verify that the user:
# can go to a specific page on the site and see all the products from the database
# can see Product Name, Description and Price for all the products

Note that I have not added the Add to Cart button specifically because this will come as part of the Add to Cart story. There is no right or wrong for ACs. Keep in mind that this is used by the developers and the QA and eventually Jeff to pass the story. The more detailed the story is the easier it is for the developers to get started. Having these on paper doesn’t imply that this is the truth or that communication shouldn’t happen.

Properties of a story
Independent
Negotiable
Valuable
Estimable
Small
Testable