Web development teams use requirements documentation to list what a customer wants. It’s that documentation that causes 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.
So, the problem starts when the scope gets translated into a requirements document.
Now we are getting serious. Because once written, that document 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 need the customer has come up with.
Does it get added to the spec? Or is it 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.
For a start, it means that you work with the customer more. You achieve what the customer 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.
The agile world prefers face-to-face conversations. Because that way, the needs for a project evolve loud and clear. 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.
Capturing user stories at this point is key. 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…”
So 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 also 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.