15 tips to master requirements to avoid scope creep and costly delays

Requirements are abused almost daily and it is a fact that most projects that fail miserably do so because the requirement process failed. Lets go over what requirements are and how to make sure you control the requirements and in doing so also control your project.

"A requirement is a legal agreement that dictates what has been agreed upon and as such it must be defined in a way that can be verified."

That is pretty much the summary of what a requirement is, but it's a bit more complicated than that as a requirement is made up of three different parts:

1. Business need - What people usually think a requirement is. Its a description of a need that should be fulfilled and it can come from the business or the end user perspective.
2. The technical elaboration - The part that is most lacking and the cause for so many failed/costly projects. This takes the business need and extend it with the technical elaborations that make it possible to design or code the solution.
3. The verification aspect - This part is where each part of the requirement is defined in a way that it can be verified with true or false statements. It ensures that the requirement have the right level of clarity.

Once you break down the requirement in these three areas you will naturally see the need to involve the correct users in the requirement process. The business need comes from the product owner, who also own the requirement. The technical elaboration comes from the developers and the verification aspects comes from test.

Once the concept that a requirement is a trinity and not a simple request or wish, then you will have come a bit closer to how to get great requirements that are easy to work with and to understand, without having to spend endless hours to formalize them. You can focus on making sure each of the three parts get improved and making sure that there is a natural handover between the requirement phase and development where the development team approves the requirement instead of just inherit it.

In order for this to work there are some things you should make sure you either stop or start doing. Here is my list of some of these things:

1. Make sure you add business value to your requirements. Requirements cost money and I don't mean when they are being developed. The cost for elaborate on a requirement also cost money so do not waste money on requirements that does not provide a clear value for the product.
2. Make sure you do not forget the "Why" in the user story! The Why often explain why the requirement exist and its what you compare against when deciding if a requirement is valuable enough to warrant the cost to realize it.
3. Make sure you break down user stories to avoid huge requirements. It is easy to end up to high in a requirement, but you need to break it down so it's easy to understand and so it fit within one development period if you are in an agile work process.
4. A requirement is NOT equal to development! There is no 1-1 relation between a requirement and development, just as there is no 1-1 relation between development and test. So unless you will start to write your requirements as a function specification do not expect development to be 1-1 with the user story.
5. Don't refer to other requirements or share user story for multiple development. Each user story is atomic and should be able to survive on it's own completely independent of other user stories. Link to solution designs and things like that, but never to another requirement in order to explain the acceptance criteria.
6. Don't describe solutions. It is up to the developer to decide on the proper technical solution and the requirement should refrain from describing solutions as the technical solution can change based on other development.
7. Never add variables in a requirement by using words like and, or, with, approx. , etc. and so on. Make the requirement clear and free from interpretations.
8. Never use indefinable terms like future proof, faster, user friendly, versatile or robust. Also refrain from using the term responsive as it's also open to interpretation.
9. Don't ramble. Each acceptance criteria should be short and verifiable. If you feel the need to explain the acceptance criteria, then it's probably not properly defined yet.
10. Make sure each acceptance criteria is verifiable. Think of them as check boxes that can be either true or false. If interpretation is needed then the acceptance criteria is not good enough.
11. Make sure that most of the questions from the development team is answered. Instead of repeating the answers over and over, write them down. In order to get this make sure you involve the developers so they can ask the questions right away.
12. Make sure the requirement take the work process in consideration. If you ask for a new component where you want to set a font color for example, then define how you would want to do that. There is a big different between getting a drop list of predefined colors, an input field for hex codes or a color wheel and it will affect your work process.
13. Always let the developers approve the requirement. This ensures that they take over the responsibility and they verify that they understand what you want them to build.
14. Once the development team have taken ownership never alter the requirement by adding or removing functionality. Only clarifications should be done at this stage or there will be mayhem and scope creep.
15. Find the right level! There is no need to go bananas and spend weeks on a requirement unless the organisation need it to get the requirement properly defined. The better each of the three parts of the requirement become at defining the requirement, the faster it will go without loosing quality. You need to find that level where the requirement is optimal for your team.

These are just some small notes on what you can do to improve the quality of requirements. I have worked with clients that knew nothing of requirements and did the Agile/Ad Hoc version where they never got a project out in time or on budget. Once properly trained they not only mastered the art of requirements, but they also managed to keep deadlines and budgets.

I aim to write a bit more about this topic later on, but perhaps there is a specific topic you would want me to address right away?