Time to Bin Your Requirements Documents
Reading time: 3 minute(s) - 600 words
Web development teams use requirements documentation to map out what a customer is asking for. It’s that documentation that cause timing problems in a project.
You know how it goes. Sales teams do the selling and then producing a scope document.
Dev teams rarely see the scoping document at that point. Which is just as well. Because if they did there would be lots of giggling, pointing and “yeah, right…” comments.
The problem starts when the scope gets translated into a requirements document.
Now we are getting serious. Because that document is written, it becomes an unchanging monolith. A stalwart of unchanging, unforgiving customer requirements for the build.
Then, the dev team start to try and build the thing. How does anyone even at this point know what’s going to happen?
You hear: “it’s in the spec…” Until it’s not. Something crops up that wasn’t in the original scope. Or it’s a new requirement the customer has come up with.
Does it get added to the spec? Or has been made so that the customer can never submit a change?
If there’s a no changes rule, it ain’t agile.
So what? I hear you say. Well, accepting changes, even late in the project, is part of the agile manifesto. And for good reason.
It means that you work with the customer more closely. You achieve what the customer really needs and everyone is happy.
Agile practitioners argue that the word requirements means compulsory, a necessary condition.
That means change has no chance. And that means agile has no chance of working, either.
In the world of agile development a face-to-face conversion is preferred. It is considered to be the best way to discover what is needed. That’s instead of writing requirements that aren’t meant to change.
It makes sense if you think about it. You’ll learn more in a 5-minute conversation that all the back-and-forth with a document.
It’s at this point that user stories should be captured. The user stories replace traditional requirements documents.
Those little snippets of information make it clear what the website should do.
As a website shopper, I want to click once on the Add to Cart Button and see my basket update so that I don’t lose which item I’m viewing.
See how it works? A simple structure of:
As a type of user I want some goal so that some reason
During the conversation with a customer, you’ll hear things like: “We don’t like it when you click Add to Basket and the page reloads…”
That’s a user story. Lots more of those and you have a master story list. Each story equates to a value the customer needs from the build.
And that’s why I master story list is always more useful than a requirements document.
You can add to the story list (and take away, that’s important to prevent scope creep).
You can change the order and the dev team can estimate and plan the stories. Life becomes a little bit easier for everyone. And you deliver the product the customer wanted.