6 Tips For Integrating Requirements Into Your Agile Process

In my previous post, I discussed the value long form requirements bring to building great software products. Requirements offer product managers & owners a powerful technique to disseminate knowledge, converge thinking, define phasing, and rigorously vet ideas before incurring the expense of execution. Next I’d like to provide a few tips on how you can seamlessly integrate requirements into your existing agile processes.

#1: Decouple Requirements From Sprints

The process of writing and reviewing requirements should be loosely coupled to your agile process. I suggest maintaining a calendar that defines the start and finish of each requirements document - ideally planning sufficiently far ahead that you always have a steady pipeline of reviewed work ready for execution. While ultimately requirements must be finished in advance of their use as stories in a sprint, I have found writing them weeks or even months in advance has the advantage of reducing the urgency and allowing my teams to do their best work. Remember: requirements represent the lowest cost time at which you can make changes to a product or feature. Once design or coding has begun, the costs will go up exponentially.

#2: Give Ample Time for Reviews

If you are rushing the development and/or review of requirements, you are doing something wrong. Two of the key values the long format narrative can bring to an organization are: (1) an opportunity to both converge the thinking around a product or feature, and (2) the ability to leverage the collective intellect of your organization to ensure you are building the right product or feature. A product manager who rushes requirements is saying to their organization: I am not interested in any feedback other than my own.

“Requirements represent the last chance to make major changes to a proposed product or feature with almost no cost. Stories have not been written, designs are not yet defined, and no one has put fingers to keyboard to produce code. A major change at this phase requires only the modification of words in a document.“

The amount of elapsed time required to move a requirements document through the phases can vary from weeks and months, usually depending on the complexity of the topic. You want to ensure you have plenty of time for your reviewers to read, gather their thoughts, discuss privately, and possibly even do their own research to ensure they give you their best feedback.

#3: Ensure Cross-Functional Attendance

The most effective requirement reviews are often the ones with the broadest attendance. I recommend reviews be attended by at least one representative from each function in an organization - e.g. engineering, product management, sales, customer service, marketing. While it is not essential for the full agile team(s) to attend the reviews, I like to ensure at a minimum, the product owners and engineering leads are there. Transparency and openness are key to ensuring product management is a company, not a department.

I regularly receive push back on the resource investment required my reviews, to which I say: is there any greater expense than the opportunity cost of building the wrong product for your customers?

#4: Create Environment For Constructive Debate & Discussion

The best product managers & owners know their job is not to tell everyone WHAT to build, but to harness the collective customer IQ of an organization to identify the right WHAT. This requires humility, a willingness to listen, and a commitment to creating an environment in which everyone feels comfortable engaging in lively discussion and debate. The most impactful requirements for my customers are almost always the ones that had the greatest engagement in their review. If you want to build great products, you need to be willing to subsume all opinions at the altar of the customer. I have learned over time a critical truth of product management: the team will always outperform the individual.

#5: Sometimes Two Reviews Is Better Than One

Over time I found more than one review was often essential to getting the best convergence of thought around a topic. I often hold the first review while my opinions were still forming, followed by a second review once the direction was more solidified. Having a several day break between reviews is a best practice that will often produce the best feedback.

#6: Treat 1st Phase as an MVF

Over time I started adding release phasing into my documents, organizing all requirements into 3-5 different releases, each representing standalone value for customers. I always pay particular attention to the first release, since it represents my Minimum Viable Feature (MVF). My goal in this first release is to bring a subset of the value to market as quickly as possible that solves a critical problem for at least some of my customers. I then allow time after the release to gather feedback from customers and adjust subsequent releases. This is of course classic Lean Startup think, where we reduce the risk of big investments by making smaller ones in the context of a continuous Build-Measure-Learn loop.

#6: Revise, Revise, Revise

Requirements, unlike a fine wine, do not age well. Their relevance is usually inversely proportional to the length of time between their development and execution. As a result, it’s critical to periodically revise these documents to keep them fresh. Minor non-feature changes can often be made without review - but any change to the actual requirements should always go back through at least a minimum review process. It is particularly important to revise your requirements after each release, ensuring you fully reflect your newly acquired validated learning. A best practice: schedule your revisions on your requirements calendar, ensuring they are always planned for instead of being reactive.