Agile Requirements Gathering: 8 Tips To Do It Better and Build a Product More Efficiently

One of the most essential advantages of the Agile methodology is the ability to adapt to changes when the project has already started. Agile requirements allow for that project flexibility and transparency compared to other traditional sequential approaches.

Detailed requirements usually are not documented all at once at the beginning of an Agile project. Instead, high-level requirements, typically in the form of user stories, form a product backlog for planning and prioritization.

In Agile, requirements are shared among customer and business analyst, product owner, scrum master, designer, development team. Usually, the team is responsible for choosing a technical approach based on high-level requirements and implementing more detailed statements or acceptance criteria in user stories.

Team goals and project specifics

In Agile, the entire team is involved in defining and optimizing acceptance criteria for user stories, implementing them, testing, and delivering results to the customers.

The development team needs to allocate time for acceptance criteria learning and investigation before starting the development process. This should be taken into consideration while estimating the feature. Everyone takes the time to stop at least to read the user story or task to understand it — ask questions, make suggestions, later estimate and explain their point of view in a grooming session. Ideally, 25% of the user story estimation should be dedicated to the requirement analysis.

If your team starts working on a new project then general info needs to be defined in the discovery phase to understand the goals of the project, who the users are, competitors, stakeholders, risks and constraints, and so on. The client typically describes the general vision of the product in the product requirements document defining all of the above-mentioned without specifying the ways to achieving the desired results. Once the client approaches the development team, further investigation may be necessary to make sure that the team and the client are on the same page. The team examines the problem from a different perspective and proposes solutions.

User stories

“A story is a work item contained in the team’s backlog” as under Dean Leffingwell’s book. A user story is a simple way to describe software requirements. It is a brief statement that describes something the system needs to do for the user. User stories are often written in a role-based structure in a form of scenarios. They may have the following template:

As a <user role>, I can <activity> so that <business value>.

According to Bill Wake, a good user story needs to be independent, negotiable, valuable, estimable, small, and testable, acronym INVEST.

Acceptance criteria

Most backlogs in Agile created at the beginning of the project are not in a good shape for the product. The reason for this is usually a lack of acceptance criteria in user stories.

“Acceptance criteria are the conditions of satisfaction being placed on the system” according to the mentioned above Dean Leffingwell’s book. These statements are described from the point of view of the user to determine when the user story is working as expected. “If all of the acceptance criteria for a user story are met, the product owner will accept the story as being completed” as under “Software Requirements” by Karl Wiegers and Joy Beatty.

It’s important to understand the client’s quality expectations and start elaborating on the acceptance criteria right from the start, which shows a thorough QA approach towards establishing adequate KPIs in accordance with the needs of the client early on in the project.

Acceptance criteria are flexible enough to change until the team starts working on the user story. Anyone in the team (BA, PO, QA, developer) can create and review the acceptance criteria.

8 ways to improve the Agile requirements gathering process:

1. Add as many details to the user story as possible.

To shorten the time for development and testing and save money for the client you should provide as many acceptance criteria to the user story as possible. Ideally, if the user story has a prototype attached, later you will be able to easily add new or edit existing user stories based on the feedback from earlier prototypes.

2. Adopt a use case approach and template.

Write basic example with required fields for creating a user story or a task in a defect management tool like Jira. Thus, a person who writes requirements won’t forget to fill in any single field.

For example:

• 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.

3. Conduct repeated grooming sessions and issue triage.

If after a grooming session some statements are still unclear, clarify this with the appropriate person, ask stakeholders their opinion on the approach. If the description isn’t detailed enough for anyone in the meeting, groom one more time until everyone is on the same page and understands feature specifics.

4. Don’t forget about prioritization.

According to the “Agile software requirements” book by Dean Leffingwell: “The product owner is responsible for determining and prioritizing user requirements and maintaining the product backlog. In support of Agile Manifesto principle #4 — Business people and developers must work together daily throughout the project — the product owner is ideally co-located with the team and participates daily with the team and its activities.” If this isn’t possible because the PO is on the customer side you can tag him/her in comments to the tickets, write e-mails, organize meetings to discuss the issues.

5. Track requirements status and communicate with stakeholders.

If someone from stakeholders or the development team has commented or replied to the question in Jira or another relevant management tool then these clarifications need to be amended or added to acceptance criteria in the user story. The same applies to design-related documents. All mock-ups should be updated in the user story not to confuse developers so that they know exactly how the feature should be designed.

A good practice here would be to invite a designer to the meeting with stakeholders and then link design explorations to the user story. If communication with stakeholders was conducted via mail/Slack/Skype, then all updated and confirmed data need to be copied to the ticket by the person responsible.

6. Use requirements management tools.

Requirements management tools give the team the ability to trace the life of the requirement back and forth, linking requirements to test cases, design specifications, etc.

7. What shouldn’t be done now.

Keep the team focused by pointing out what you’re not doing. According to Atlassian: “Flag things that are out of scope at the moment, but might be considered at a later time.”

8. Demo the user story to the stakeholders before releasing to production.

Usually, people don’t always know what they need until they see what they get. Often stakeholders change initial requirements after seeing the full picture and may ask for corrections. You can easily add new or edit existing requirements based on the feedback and new priorities from decision-makers.

So summarizing all mentioned above:

Wrapping Up

One of the key points of the project success is to figure out how to gather requirements in Agile efficiently and in a way that will most benefit the team and the project. The main focus of Agile is the value of the product it brings for the users. A common practice in Agile is to change requirements during the development process. The result is an increment that may be ready right after one iteration. Usually, the development team is presenting a demo to the customer who can see how the product is working and may suggest improvements. This helps to prevent unnecessary delays and increased costs. Thus, the 3rd principle of the Agile manifesto “Customer collaboration over contract negotiation” is resulting in quicker delivery and value for the users.

And finally, product owner, business analyst, and the development team will learn more about the product as the project progresses, particularly once the software is already in use. This means that they will have more experience from previous iterations and can leverage requirements gathering best practices to achieve better results in each consecutive cycle of the project.