Agile Requirements - How do you eat yours?

One of the things that I have been looking at a lot recently is the definition of what we, as a team, are building – a commonly missed task by many teams which can often lead to cowboy coding.

Now, there are many viewpoints on how this can be done, the age old preference being that of creating a 10,000 document that everyone must adhere to and be measured by. The trouble is, the document takes months to write, even longer to get approval on, and then an eon to code. By the end of this process, the document owner has retired, the development team have cycled their staff three times, and your dog has died. But, more importantly, because these days is moving so damn fast in business, your document is now worthless as half of the requirements are now invalid – either because the workflows in place have subtly changed or the market the product is aimed at has.

So, what do we do about this? Do we just ignore the requirement making it up as we go along, or do we do something a little more clever. Most people seem to leave it to making it up as you go along.

1. Ask engineer how the damn thing works.
2. Deafing silence.
3. Crickets.
4. Tumbleweed.
5. Just start writing something. Anything.
6. Give this something to the engineer.
7. Watch engineer become quite upset at how badly you’ve missed the point of everything.
8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
9. Collect these nuggets, as they are the only reliable technical information you will receive.
10. Try like hell to weave together this information into something enlightening and technically accurate.
11. Go to step 6.

Well, at Monochrome, we’ve been doing Agile now for a fair while, and the key mantra there is

“Just barely good enough“

But what does this mean? Well, in essence, don’t bother doing anything until literally just before you need it, and even then, only do the absolute minimum to makes things work. If you do things to early, you’re opening up the risk of change, and if you do too much, you’re pretty much wasting your time (the minimum amount is just enough after all). This means no massive tombs of out of date guff, and also a lot less time spent writing.

For us, we find that documentation in the form of multiple screen wireframes that are annotated with functional detail tend to suffice, especially when accompanied by some background blurb to describe the things you can’t see. This is especially effective for two reasons – firstly it’s nice and visual, which means clients are more likely to read it, and it also gives you a nice document to directly compare your screens and functionality against – it’s almost testable.

Now, here’s a question back to you guys, all of which will be either reading, writing or somehow interacting with requirements on a daily basis – how do you eat yours? What do you find works, and what do you wish you could have?

Posted by Neil Middleton on 16 Mar 2009