What Are Good Requirements?
What makes a good requirement?
That’s something that is completely open to interpretation. In my humble opinion, a good requirement is one that is clear and direct. It communicates what it is supposed to and then moves on.
No muss, no fuss.
There are many out there that will disagree with me on this. That’s OK - it’s all open to interpretation and what you’ve seen work before, or have tried, have succeeded with, have failed at, etc…
See to me, in the scenarios where development is not run by product (which should be every scenario if you want to do things right) you need to have a good partnership there. If that doesn’t exist, things will go down the tubes pretty quickly. That being said, you don’t have to love each other and hold hands - but something has to be shipped.
Now, to boil this down pretty quickly, I really see there being only two types of requirements:
1. Agile requirements; and
2. Waterfall requirements
These are really polar opposites of one another. You can’t get much different, aside from the fact that you are communicating the same problem you want solved within each - they are both just different ways to communicate them.
The thing I have come to realize is that for agile to work - for it to really work - you need everyone behind it and you need pretty smart developers who are on the ball. The main reason for this is that you want great code to be written, but the time you are saving by not writing long (and I mean looong) requirements documents produces ambiguity, and that must be filled in by the developer as they go.
They must ask questions. They must talk to you (the product wonk). And above all, you must trust each other.
Some developers have serious issues working this way - I get it. I understand it’s not easy. It puts a lot of onus on those that are writing the code, as opposed to the waterfall way….
Now in waterfall, at least in my experience, you are pushing away communication in favor of documentation. Developers want every single piece of a feature mocked-up, written down, and worked out before they even start thinking about the code. I always picture this style of process as taking things and lobbing them over walls. Requirements over a wall to dev, code over a wall to QA, QA over a wall to production, etc, etc…
Especially if your team is small, working this way is not leveraging one of the team’s crucial strengths - it’s size.
A lot of companies work in waterfall, and it does have its place. Specifically in organizations that demand a heavy process workflow through a release - or something that has a ton of formal check points. Two examples here (respectively) could be a bank and a consultancy
If you are going gangbusters trying to get products out the door, the last thing you need are formal check points. The last thing you need are 50-100+ page requirements documents. But that is what happens. This gums up the works for several key reasons.
The main one is, people stop talking. They stop asking questions. They just assume they can blindly follow the documentation - and if it doesn’t turn out right, oh well - wasn’t documented that way, so it’s becomes a bug. People way smarter than me came up with the agile manifesto for a reason. It can and does work.
People are smarter than this and everyone should expect them to be.
Of course developers need things to go on. You can’t expect them to read your mind and they can’t design anything (in most cases). But they are smart. After all, they are computer programmers.
The bottom line is this - no one can tell the future. As features get implemented, they change. Sure you know a lot of things up-front (button goes here, text goes there, save this, etc…) but you are 100% bound to miss things. If your product release process doesn’t account for things being missed down stream, it’s wrong.
Remember one of the key tenets of agile - put things off as long as possible until the last possible moment you can decide to ensure you have the best set of information at hand to make that decision.
Those things don’t happen in closed-door offices with a product manager huddled over his keyboard typing out requirements and acceptance criteria fast and furious. They happen in talking to those coding out those ideas and breathing life in to them.
But, not all teams are cut out for that sort of challenge. And that’s OK too - just make sure your management team knows you are going to need a solid chunk of time (1 1/2-2 months) per release cycle. And make sure you have some spare toner and paper ready for your printer. You’re going to be doing a lot of editing on those requirements docs.
Agile Risks
It’s easy to get taken with the simplicity of agile. Less requirements to write, less documentation, less time planning - but it all pans out in the end. I find that once you are in the thick of it, there are intricacies that can really bite you in the ass if they don’t have the proper attention paid to them.
Let me provide an example that has to do with requirements - writing them, providing them to development, and just their overall management.
If you write a one-line requirement, develop your workflows, and then your wireframes and send it on over to development, is there a risk they won’t get it? Um, yes. For sure.
Now, on the flip side, could you spend a lot more time writing those requirements, break out each permutation and case, and then send it on to development and still have them make incorrect assumptions? Yep - probably much less of chance, seeing as the requirement would box the developer into exactly what needs to be executed, but there is still a chance.
But, will it take you much longer to write that requirement? Yes. Will there be more documentation produced as a result? Yes. Will people talk more, or read more? Read more. Is that bad? In my book, yes it is folks.
See, you want people talking as much as possible. Communication. Remember that thing people did before e-mail and telephone? They actually talked to one another - face-to-face. Why people don’t do this as much now is left up to a myriad of reasons. However, the “agile” style of simple requirements (i.e., capture the damn idea and what it is supposed to do, design it so you don’t have developers opening up Photoshop and churning out graphics, and write all the necessary associated copy, etc.) will intentionally drive more and more communication.
The product manager should be ahead of the release curve. We do one release per month and I’m already planning May. This is highly ideal (while not always possible in every scenario) because I have a ton more bandwidth to provide the necessary attention to, and answer the questions about, how certain requirements are to work.
Now, developers of course need to know when to ask the questions. Because this style of requirements leave a lot more flexibility (by design), they need to know it’s OK to say, “alright, product flunky, I don’t get it. Why is it supposed to work this way?” To which I would reply, “for reasons X, Y, Z” or, “um, I dunno. Good call - you got me. Let’s make a change.”
Now, how does this relate to risk? Well, of course, this method leaves you open to having development mis-intepret the requirements, not ask about them because they believe to understand them and they are seemingly clear, and they get implemented wrong.
This is bad, but hey - agile is all about iterations. Sure, expect to get possibly lambasted for not getting something out the door because the requirements weren’t understood (PMs, I’m talking to you - a release is your responsibility), but at the end of the day, it’s one of the key agile risks.
You could toil away in your office, spend three weeks writing requirements for a single feature (been there, done that) and then always be “catching up” or “not getting stuff done on time due to having a lack of time to do it.” Or, just document what it’s supposed to do and trust your developers (because they are really super smart people) to interpret and understand, and know when to ask questions.
Then, expect you’ll have some good conversations, and possibly some healthy conflicts, over what something is supposed to do. And that, my dear friends, means the product is going to be a lot better at the end of the day.
