Monthly Archives: September 2010

The "Worst/Best" Requirements Game

In an Agile project trying to get useful functional requirements from your business can be a painful task. Unless they are experience Agile practitioners, it’s like asking a home-owner to design a house. The requirements they give you will be completely different than what an architect would give you and is pretty likely to be not completely thought out; bits will be missed out, specific guidance on how particular bits should be done will be lacking so something that passes all the acceptance criteria will have to be torn down and done again.

Now I know that Agile allows you to revisit areas and refactor them but wouldn’t it be nice to get the business to give you a set of specs that looks at things from multiple perspectives. That way you would be more likely to get a coherent set of requirements with only a few missing bits that are easy to work to.

The next time I need to get requirements I’m going to use the carrot and stick approach. I’m going to get a whiteboard, draw a line down the middle, write “WORST” on the left half and “BEST” on the right. When business have to come up with requirements I want them to come up with the most painful process that would actually work and write that down in the WORST side. I want them to think about the most inept way they can get something done. Once they got that down, only then do they get to describe their ideal solution in the BEST side. This way they are forced to think about the worst case scenarios, the inefficiencies, the bloody-minded stupidities the faffing about that always surround inefficient solutions and deliberately steer away from them.

Of course this is nothing new, it’s just a matter of negative and positive requirements (“must do X, must not do Y”), but it seems a nice understandable way to encourage business folk who don’t have much experience with Agile to interact with development.