Monthly Archives: October 2008

How to do Agile Properly – Part 1: Preparation with Stories

Agile is A Good Thing. It gives us room to be flexible with our projects, and when implemented right can be a genuinely much more productive way to work. Even so, I see so many overspills from legacy processes that just hold us back, and people are reluctant to change. Today we have tools available that go so much further than “Track Changes” in a Word Document.

In this series, I will try to give my ideas about how an Agile project should work, from start to finish. It won’t be perfect (everyone does it differently) and my terminology might not match yours, but I hope it’s helpful. If you have comments, please, let me know. After all – even the process of Agile is agile itself!

Everything Starts With Stories

The first thing we need is a plan for our project: what we want it to do, how it should work and what we want to achieve.

I have made the assumption you already have a good idea of how your project will work – this is not a series about getting ideas or brainstorming.

For the sake of example, we’ll say we want to make a website that sells shoes. So, we’ve got a warehouse full of shoes. We’ve got people ready to send them off, and we’ve got a bank account to take the cash. But what is it we actually need to do to sell them online?

Stories (or User Stories) are a nice way of formalising our requirements. We just need a sentence, formed like:

As a(n) A I want (to) B so that C.

A is the person we are creating this requirement for, usually the User, but could also be the Developer, the Product Owner, the Tester, etc. It’s good to have this list formalised before-hand, so we’ll go with:

  • User
  • Developer
  • Product Owner

B is the actual requirement. This doesn’t need to be too specific; we capture the specifics in Acceptance Critera.
C is our justification for this requirement.

Here’s a good example:

As a User
I want to add a pair of shoes to my shopping basket
So that I can buy these shoes when I check-out.

This assumes we already have a page showing us shoes, but no way yet to buy them. Without yet going into the technicalities, we can now write Acceptance Critera.

Acceptance Criteria are a list of tasks which will either pass or fail, and inform us as to whether or not we have satisfied this story. These serve as a quick checklist to make sure the story was completed. We can prefix these with priorities, so that we know how imporant they are. Here’s a typical list of priorities:

  • Must – this criteria must be satisfied or we cannot release this project.
  • Should – this criteria should be satisfied, but we can release the project without it, and address it in the future.
  • Could – this criteria could be satisfied (it is nice-to-have) but we can release the project without it, and may never implement it if more important things come up.

With these in mind, we can now write acceptance critera for this story:

  • Must – An “Add to Basket” button is displayed alongside each pair of shoes
  • Must – When clicking the button, the pair is added to the basket
  • Should – The basket should visibly update immediately
  • Could – An animation could give a visual indicatation that the pair has been added to the basket

I recommend writing a “Project Story” so that you never lose sight of exactly what your project is supposed to achieve, before you get into the fine details. An example of our Project Story might be:

As a User
I want to browse through a catalogue of shoes and purchase them
So that I can satisfy my desires to be fashionable or protect my feet in various environments.

Acceptance Critera:

  • Must – The user can browse a catalogue of shoes
  • Must – The user can purchase any of these pairs of shoes

Now we’re in a good place to write the rest of the stories. We should cover how the browsing of the catalogue works, the checkout process, how we cope with items that are out of stock. We should also deal with Non-Functional Requirements like the kind of response time we expect for our site, and how much traffic it should be able to handle. At the end of this story-writing (aside from feeling like a novelist), we should have a comprehensive list of stories that detail what we can expect from our project.


We need ways to capture all of these stories, and manage them as we progress. Once upon a time, we would use Excel or Word, but that gives us a static file and isn’t great for sharing or collaboration. I would recommend using a wiki to achieve this. MediaWiki is a great option; it’s free and open source, and forms the base for Wikipedia. If you’ve got some cash splashing around though, the best option (I think) is Confluence. At $1200 for up to 25 users it’s not unreasonably priced, and supports all kinds of clever plug-ins and so on. It even has a pretty good WYSIWYG editor, so that you don’t terrify the business with mark-up. For a lot of this series, I will assume you are using Confluence, but will try to make it clear where functionality is Confluence-specific.

Once you have these stories in your wiki you can share them with the rest of the team, and bounce them back and forward until they seem pretty solid, and everyone has a good understanding of how the project will work from the user’s perspective.

In part 2, I will go into how the design team get involved, and look at wireframes, and designs.