What is Requirements Management?

Requirements provide an outline of an acceptable solution for the team that is building features for the product.  Designers create an experience, Engineers develop systems, and Data Scientists create predictive models to solve the problems that have been prioritized and defined by Product.  When done well, a requirement is not prescriptive – Product works in the “problem space” to understand the problem and what a viable solution should be, and it Is the team who works in the “solution space” to then design that solution to the defined problem.  

Putting Requirements into perspective, they define specific aspects of a solution, Product of Feature. More often than not, a Requirement describes a dimension of a new feature the team is working on for the Product.  In the previous guide about Strategy Planning, we discussed how a Vision, Objectives, and Themes are formed.   The next layer down is defining the specific projects that will bring about the features and capabilities we wish to see in the product.  Each of those “feature projects” has a level of definition as well as contains a set of requirements for that feature. In this guide, we’ll discuss the definition of those projects and requirements.  

What is a Feature Project?

A project is something that is large enough to create value for the customer and encompasses multiple requirements that describe aspects of the solution and generally analogous to an Epic in Agile/Scrum.  It is generally something that is larger than a sprint of work and big enough that you’d put it onto your roadmap. 

There are two types of projects generally – Feature Projects that are useful and usable to the user, and Capability Projects that introduce new capabilities to the platform/system, that future features can be built upon.   

For the most part in Product Development, you’ll be working on Feature Projects, but it is good practice to work with your technical partners and set aside bandwidth for those enabling capabilities. 

Feature Project Definition

Unlike how most Scrum teams use Epics as merely containers for related User Stories, Product Management needs to do real work to define the feature at this level. A feature is more than just a collection of requirements – there is context and purpose that is greater than the sum of its parts, and articulating that is helpful both for clarifying one’s one thoughts and communicating that to the team for alignment.  As Dave McCullough eloquently put it “Writing is thinking. To write well is to think clearly. That’s why it is so hard”.   

And so, let’s think about this in terms of defining a feature.  We’ll want one document to serve as a “single source of truth” landing page, that the team can easily find and reference.  We’ll want to keep it concise but offer the following basic information: 

One Page, NOT a PRD

Creating a PRD has become taboo in iterative software development because it is overkill and doesn’t fit with the perspectives of Agile.  Product Managers would create very large documents (50-100 pages) that prescribed every nuance of a product to be created and spend inordinate amounts of time creating it.  This had two negative outcomes – it would slow the entire process down considerably since the PRD had to be created before development could begin, and are demoralizing for teams who were told exactly what to build rather than engaging them in the creative solutioning process. 

That doesn’t mean there is no value in crystallizing the context and purpose at a feature project level though – quite the contrary!  The solution is to create a “one page” document that concisely describes the feature in a meaningful way, but without getting too carried away or disenfranchising the team from designing the solution.  That balanced and lightweight solution is what is described here. 

Writing Requirements

Once a feature has been sufficiently defined at the project level, it is time to write the requirements that will provide the bounds of a sufficient solution for the team to work against.  

In traditional Business Analysis, there are many types of requirements – Functional Requirements describe a technical perspective, Non-Functional Requirements describe an internal process such as QA against those functional requirements, Business Requirements describe an expectation of internal business stakeholders, and yes, User Requirements which describe external user/customer expectations.  In Agile/Scrum development, this distinction is lost and most requirements are written as User Stories, which describe the problem in a narrative form, from the user’s perspective.  

User Stories

Consistent with the philosophy of Agile, User Stories are intentionally non-prescriptive and merely describe a scenario to inform the team during solution design.  They are usually written in the form of: “As a [who] I want [what] so that [why]”.   For example, “As a customer I want to see recent orders in my account so that I can track the order and know when it will arrive.”  

Optimal User Stories follow the INVEST principles which means they’re independent from one another (no dependencies), independently negotiable and valuable, specific enough that the team can estimate them with story points, small enough to complete within a single sprint and testable/verifiable through QA processes, that are typically keyed from your acceptance criteria.  Read more about User Stories. 

The following template can be useful for defining these requirements.

Managing the Backlog

The Product Backlog is where all the requirements come together for prioritization. Once you’ve created a couple of feature projects, you might have a dozen or two requirements from those sources.  That’s not the only source of requirements though – they can come in the form of “loose leaf” continuous improvements, A/B testing hypotheses, support requests from stakeholders, technical stories to refactor, or any number of other sources. Ultimately all of these requirements come together in a single backlog for prioritization. 

Prioritizing the Backlog

With all of the requirements in your product backlog, how do you decide which ones to prioritize in a given sprint (development increment)?  

It is good to have a time allocation model in mind, that budgets your time for the upcoming sprint.  For example, a good rule of thumb might be to spend 60% of your time on those feature projects that are on your roadmap, and set aside 20% for continuous improvement activities such as A/B tests and refining the UI, 10% for tech debt or other tech initiatives, and 10% for support activities such as stakeholder requests.  The time allocation model is going to be different for every organization, but defining and aligning on that ahead of time will prevent a lot of difficult conversations down the road as well as ensure you’re staying true to your longer-term goals and responsibilities.

Release Planning

Release planning is the process of determining how a new feature will be made available to the user.  Since features are meaningful functionality for the user that is both useful, usable, and valuable to the customer, it is often an aggregation of requirements user stories that spans multiple sprints.  As such, Product needs to work with its technical partners to devise a plan for how to release this feature.   

Every team has a little bit different release process – some use a “release train” every few weeks in which all features that are for a release must be readied on the same cadence in order to catch that next ‘train’.   In other cases, a team may practice Continuous Deployment, meaning Stories are released incrementally, as they are completed. In both cases though, completion of an individual requirement / user story doesn’t necessarily mean the full feature that is valuable to a customer is ready to be released for use.  Internal teams can also be caught off guard and not ready to support the new feature. Not considering this and indiscriminately releasing every increment directly to the customer can be frustrating for everyone involved. 

A better approach is to implement a “feature flag” that suppresses the feature until everything is aligned to provide the full new increment to the customer.  Technical teams can deploy code in whatever manner works best for them and we simply “flag on” the feature when it is ready. 

To this end, it is wise to plan feature release in advance, so the user stories can be lined up properly in the development cycles that follow.   Every sprint may include requirements for a key feature but also requirements for a few other things going on such as continuous improvement and support requests – but we must be able to see a clear plan for when those larger roadmap features will be ready to launch and plan those streams accordingly, to ensure everything is properly coordinated and feature release appears flawless to both our customers and internal stakeholders. 

Requirements Archival

It is easy to think of a requirement as complete once it is released but there are many times when you’ll still need to refer back to requirements after they have gone live.  As systems become mature and complex, it is not uncommon that a knowledge of those initial behaviors and rules have not been documented and the people that had this legacy knowledge have moved on from the team.  People can forget why the system behaves the way it does, and regression testing can omit these requirements from coverage. For this reason, it is important that legacy requirements be discoverable and referenceable after they have gone live.  This enables Product teams can do research and QA teams can link their tests cases to these requirements.

Conclusion

Requirements are the DNA of our product and detail the specific behaviors and outcomes we want to achieve with a new feature.  Requirements are defined as part of a feature project but can also be defined independently for smaller activities such as A/B testing or continuous improvement.  All of this ends up in our Product Backlog, requiring prioritization to ensure priorities for our team resources are managed appropriately. Defining a time allocation model and aligning internal teams to this, help to budget time across features on the roadmap and everything else the team must accommodate.  Finally, we must orchestrate the release of new features in a coordinated and thoughtful way to maximize perceived value by the customer and minimize internal confusion. Following these steps will ensure the ability to consistently and efficiently deliver value for your customers.