During the Lean transformation in my current company we get to learn lots of new things and unlearn a lot of old ones as we familiarise ourselves with new concepts and tools.
One of the fundamental agile tools in the space of requirements capture is using user stories rather than previously used use cases or functional specifications. User stories should be sort, concise, specific, usually written on a small card and usually following the ubiquitous pattern (As a … I want to … so that …). On the back of the card, there would usually be some acceptance criteria so that we know how to test it and see when the particular story is done.
In a discussion with one of the analysts today, reflecting on a previous sprint I’ve heard: “I’m certainly getting better at those user stories – for the last few I’ve written I had no questions at all from developers or testers“. Well, that’s great I though and… panicked! How deeply rooted we still are in the old days and the old ideas – documentation is everything.
User stories are not a different format of the spec that fully express any given (perhaps more fine-grained) requirement. They should be place-holders for conversation. Statements of requirements indeed but ones that need to be explored and enhanced in collaboration of the development team and the business side.
We still have a lot to learn – or rather unlearn. (And perhaps shrinking the cards will help?)