If seeing the word “Agile” in a requirements gathering blog has you confused, you’re not alone. In fact, if you’re trying to get a straight answer about Agile requirements gathering, this page may be one attempt of many. The truth is: it is a difficult process to define.
Two big reasons for this are:
- Not every project can be built in an Agile way. Especially one that requires a PRD (product requirements document).
- One of the major goals in Agile is to reduce documentation. And yet requirements are very much documented, and are very much necessary documentation if you’re in a regulated industry.
So where does that leave us?
You’re probably not in a pure Agile environment, so you know the deal. The key is to get ideas around how to make this work, and apply what fits for your team. (Spoiler alert: this is a whole lot easier with a requirements management tool suited for hybrid Agile).
Whether you’re here to learn about traditional / Waterfall or Agile requirements gathering, here are some explanations, techniques, and templates we hope will help.
Read on or skip to the section that interests you most:
Back to top
What Is Requirements Gathering?
Requirements gathering is the process of collecting a project’s exact requirements from start to finish — including functional, non-functional, business, user, and regulatory requirements.
It’s an exploratory activity with the ultimate goal of defining all the product criteria in a PRD for the product development team to use as a blueprint.
This document typically includes:
- Purpose — Who it’s for and why you’re building it.
- Features — What you’re building.
- Release/Acceptance Criteria — What the requirement must have to be accepted by stakeholders
- Timeline — Your goal for the release.
The purpose of requirements gathering and the PRD is basically to ensure that the final product meets all expectations, which is especially important when compliance is a goal. Failure to provide accurate requirements can result in anything from project delays to project failure.
Back to top
How is Agile Requirements Gathering Different?
Traditional (Waterfall) project requirements are set early on in development, at which point they are reviewed and approved. Approved requirements don’t often change. Customer feedback does not usually inform requirements, and typically comes via bug fixes or features. The PRD clearly outlines what the requirements are, not why they need to be met.
Conversely, Agile requirements adhere more to the Agile manifesto. For instance, they put the customer first by outlining what the requirements are and why they matter to the user or stakeholder in the form of a user story. Gathering requirements is a collaborative process in which stakeholders review and update requirements throughout the development lifecycle. While, again, the process may not be purely Agile, requirements gathering should allow teams to embrace change, especially through frequent delivery and face-to-face conversations, for example.
Gathering user stories for a release still covers the same elements of a traditional PRD — purpose, features, criteria, and timeline. However, the Agile document usually lives through some sort of interactive document or task board that enables simplicity, whereas a traditional PRD is a static document.
Back to top
How to Gather Requirements
To cover your bases, you need to consult all necessary sources of your project requirements. These are typically stakeholders — including customers, users, administrators, business partners, compliance managers, and other relevant experts. You can obtain the information from them in a number of ways described below in the section on techniques.
From a requirements management perspective, it may be helpful to look at the process of requirements gathering like this (and remember to maintain documentation!):
1. Assign roles.
2. Conduct stakeholder interviews.
3. List requirements and expectations.
4. Monitor and track requirements.
5. Get feedback.
Evaluating Requirements Management Solutions?
Get our Requirements Management Software Buyer's Guide to learn 5 questions to ask when comparing traceability and compliance solutions.
How to Make it Agile
Agile requirements gathering will be more collaborative, where developers will be included in conversations about what is needed and why. As mentioned above, the process will also take place throughout development when possible.
For those stringent requirements, like regulatory requirements, you may still need to follow a more traditional approach — but include links to static documents within the user stories to define strict parameters. This is made easier by using a requirements management tool that accommodates hybrid Agile environments.
The above list may be amended with principles from the Agile manifesto:
1. Have teams form groups.
2. Ask customer for requirements (face-to-face when possible) and deliver ASAP.
3. Discuss via daily meetings of Business and Dev teams.
4. Measure progress through working software.
5. Continue to obtain feedback and embrace customer change.
6. Reflect and grow.
Learn how to reuse requirements for easier requirements gathering >>
Back to top
Requirements Gathering Techniques
When you have a list of relevant sources, there are a number of ways you can go about capturing the requirements. It’s good to use more than one approach so that you don’t miss anything. Here are five strong techniques to consider.
Brainstorming
A good old-fashioned brainstorming session is certainly worth the effort. Participants talk about what they think is important without criticism or debate. After, a facilitator (usually the product owner) helps to reshape the ideas and then organizes and prioritizes them.
Interviews or Questionnaires
Talk directly to stakeholders about what problems the product solves, background information about business needs, and any other concerns to consider. If you can’t get a meeting in, a well-developed survey with open-ended questions can get you the information you need. (But in-person is preferred so the conversation is dynamic.)
Review Similar or Current Systems
If it’s possible to review the requirements and other system documentation from a similar system (or the current one you may be replacing,) this can provide a valuable framework to start with.
Observe or Work in the Target Environment
If it’s feasible to submerge yourself in the user experience — either actively (participate yourself) or passively (ask questions while you observe someone else) — you may be able to get a better understanding of what’s required and also what should be improved upon.
Talk to Support Teams
Support engineers and help desks may be able to save you time by sharing problems and fixes that a similar or current project has needed in the past. Training and installation teams can shed light on what users find difficult about implementation.
Learn how to streamline requirements gathering like a pro.
🖥️ Watch the on-demand webinar:
Essential Tips for Modern Requirements Management >>
Back to top
Agile Requirements Gathering Techniques
As mentioned above, the information you’re aiming to get still answers the basic outline of purpose, features, criteria, and timeline. Some differences lie in the way you will document, use the information, and potentially the way you organize or prioritize the requirements.
Detail User Stories With Critical Links
Rather than create requirements statements, you’re describing what’s needed and why through user stories. When it comes to things like compliance, you need that information available without compromising the simplicity of the user story. In these cases, add links within the stories to pertinent documents. Additionally, you can provide acceptance criteria in the user stories to provide the right amount of detail. (We outline an example in the template section below.)
Prioritize
It’s not that you don’t assign priorities in Waterfall; you do. But here you should still rely on your product owner to prioritize the user requirements and maintain a backlog like usual where possible. You may still use index cards, a Kanban board, or whatever Agile methodology makes your team successful.
Track Status and Communication With Stakeholders
As you’re working through sprints and sharing updates with stakeholders, track feedback. It’s wise to use a tool that allows you to link their comments to the user stories.
Use Prototypes
This is a great example of how Agile requirements gathering does not all happen before the project begins. You can get valuable information from stakeholders by sharing a demo or prototype before the build or final release. People don’t always know what they need until they see the end result, so you can save a lot of rework with a sneak peek.
Use a Requirements Management Tool
This is exceptionally helpful for a couple of reasons. First, (and especially if compliance is of concern,) you can use a tool like Helix ALM to have end-to-end traceability among your requirements, issues, and test cases. It’s more than handy when trying to maintain documentation in the anti-documentation world of Agile. Second, the tool should spare you the need for a manual template — and dropdowns and pre-populated fields will help you build user stories much more quickly. Talk about agility!
Back to topRequirements Gathering Template
If you don’t need traceability and you don’t have a tool with a built-in template, you can probably find a suitable requirements gathering template in Microsoft Excel that looks something like this:
You could also just outline everything in Microsoft Word, which might look like this:
There are a number of downsides to using a spreadsheet or Word-based requirement gathering template. Outside of traceability complications, it’s incredibly hard to maintain version control. People often struggle to hunt down the most recent version and check that it captures everyone’s feedback — or sometimes the document owner is unavailable and you don’t know where he or she saved the file.
Also, it isn’t as available to all the teams who need it if it’s stored outside of the tools they’re using to build or test the project. It’s difficult to use in Waterfall development, and nearly impossible in Agile.
A requirements management tool solves these problems, and makes it much easier to perform your tasks. Here’s what your requirements gathering template could look like within Helix ALM:
Agile Requirements Gathering Template
If you don’t want to use Helix ALM or another tool that lets you format requirements into more of a Scrum/Sprint model, there are a couple of outlines that can be helpful to you in this process.
The first is an alternative to a lengthy PRD. As you add your gathered requirements, you can simplify for Agile by using a one-page document. This is still easiest to accomplish within a tool, and if you’re a true-blue Jira user, you may be able to get this through Confluence — the benefit being you can provide Jira links in the requirements template. (If you need the traceability that Jira does not provide, tools like Helix ALM also integrate with Jira and do not require plugins to be configurable out of the box.) Atlassian plugs their template here, and it has an outline you may be able to use. To sum up, they recommend you define:
- Specifics of the project, like participants, status, and target release.
- Team goals and business objectives.
- Background and strategic fit.
- Assumptions.
- User stories (including the title | description | priority | notes.)
- Links to design explorations and wireframes.
- Questions to track based on the requirements.
- A list of things you’re not doing because they’re out of scope.
If you’re not married to Jira or Confluence, you can use a similar template with pre-populated fields in other tools. Here’s an example of a Kanban board from Helix ALM:
You can also monitor the progress of a sprint in Helix ALM, which might look like this:
Another item that may be useful to you as you create your Agile requirements gathering template and build user stories is a user acceptance criteria outline from Agile Insider. They recommend you create a doc with these fields:
- Acceptance criteria
- Scenarios
- Design
- Web/native
- How to demo the user story
- Mobile/tablet/desktop
- All needed hardware/software available for testing
- Platforms
- Affected areas to test
- Where/when needed to be delivered
- PO/BA/Designers POC
- Error handling
A requirements management tool should have pre-populated dropdowns to use, which simplifies the process to make it more Agile, too. In fact, you can have other project information that would normally require time to document available as dropdowns when you add a requirement so that the process is more Agile, yet you preserve any necessary documentation. Here’s what that might look like:
Ultimately, the Agile requirements gathering template will help you focus more on getting work done than inputting data. And you can accomplish that with shortcuts like dropdowns, or lean dashboards and other task views that let you see only the information you need.
Back to topSimplify Requirements Gathering
Whether you use Waterfall or Agile methodology, requirements gathering takes some work. And either way, you need at least some documentation. The best way to do this is to use a tool that outlines the information you need, organizes it in the way your team works, and enables collaboration across teams. See for yourself how much easier this is in Helix ALM by trying it out for free, or by watching the on-demand demo.