Writing Agile Specifications

It all started with diagrams that were filled out very soon with lot of wording, then just plain English Use Cases and finally a combination of wireframe diagrams and user stories.

Now we can deliver while hapilly checking things off the list in a daily basis.

It was all written years ago but still so many of us were trying to go around the inevitable, you must INVEST in good user stories. No need to find culprits, let’s get agile right from the beginning: The “specs”.

Don’t get too extreme though. Nobody said you cannot extend the written portion a little bit so a whole use case makes sense when joining the different scenarios.

1. Do it your way: XP, Scrum or a combination but make sure stake holders know what you will be delivering. Make them participate on the creation of scenarios (User stories) and wireframes. Try (why not?) making them comfortable with the tools (simple tools, keep on reading) you use. You might be surprised finding out that some of them can even provide a whole specification that is actually testable and implementable! If you have a Business Analyst (BA) then you are in luck, without any doubts s(he) will need to become your “story teller” (quoting here the guy behind http://masterstoryteller.co.uk) and your "Mock up drawer".

2. Keep it as short as possible and do the job incremental but without losing the most important features so the software can be used right from first release in production.

3. Make sure the developers agree the scenarios are feasible and commit to get it done in a reasonable amount of time. Without the right crew there is no possible agility.

Writing the Specs

1. Use a rich editor where you can put images on the left and text on the right. Google Documents is perfect for sharing, versioning, and ... well it is Google you know. I just use a two columns table. Google allows to insert the picture from local File System, from URL or web search.

2. Draw a flat wireframe using paper and pencil. Yes just use an eraser for corrections ;-) I commonly use copies of a master template which contains things that are fixed for most of the site like the basic footer, content and header layout.

3. Take a picture of it and put it in the left column. I commonly use an Android phone and upload the picture directly to Picasa. From Google Documents you can import its URL as I said. And yes you can resize to meet half of your landscape page or to get more details about it as Google will save the whole raster image and not just the resized result.

4. Write your user story. Yes, try to make it short but not shorter than needed! (Modified Einstein words here ;-) The most important part is that what you write you can test. In a User story (if well written) you can get the needed information for a developer to provide behavioral/functional/integration tests and at the same time for you as a BA to confirm the delivered product meets the business requirements.

Below is a screen shot taken from Google Docs.