Tuesday, July 14, 2009

What's the best way to specify requirements?

Are user stories better than other types of requirements specification?

User stories are narrative texts that focus on the value a user gains from the system. The basic thing about a real user story is that it's a metaphor for the work being done, not a highly documented requirement. The intent is to enhance collaboration about the topic of the user story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration.

We value people over process, remember? Any technique may be flawed, but it’s the individual and team that can make it work or fail . If someone is used to iterative approach I believe they can make the other use cases and user stories work. If someone is steeped in big requirements up front (BRUF) then they will bring that style to user stories and end up with traditional requirements that are termed stories. At the end of the day it’s the individual that’ll make a technique fail or succeed.

As agile coaches and authors, we stress people and the importance of people and the team, but all too often focus on techniques, not the intent of the techniques or the underlying values of the agile manifesto.

So are user stories the best way to document requirements? Yes, if and only if you can foster collaboration. If your writing user stories and not seeing collaboration, the user stories are not helping and you might as well write traditional requirements (or better yet start to emphasize collaboration).

No comments: