This content is part of the Essential Guide: Gathering and managing software project requirements
Get started Bring yourself up to speed with our introductory content.

Techniques for gathering requirements in Agile scrum

Discovering Agile requirements: story mapping, the scrum master role and tools that increase the team's ability to communicate effectively can help.

Gathering or generating requirements in an Agile development system is unique because it's flexible. Often customers,...

product owners, testers and the development team (all available stakeholders) take an active role in generating user stories for new features and determining requirements. Requirements in Agile scrum are ever-changing and designed to remain flexible as needs change or as new design considerations are discovered.

Discovery is a good word to describe gathering requirements in Agile. It's a process of discovering design along the way to ensure the final requirements meet the customer's needs. Because code is released intermittently, internal and external customers, testers and engineers have time to fully consider the design needs of the application feature.

Several aspects come together when discovering requirements, including techniques such as story mapping, the scrum master role and an array of tools that increase the team's ability to communicate and interact effectively.

Gathering requirements: Story mapping techniques

Story mapping allows a team to visually map out user stories and discover feature design through active discussions. Story mapping focuses on fleshing out the full feature design, starting with the initial vertical slice to the final fully functional feature. Along the way, as user stories are written and discussed, the actual system requirements are gathered. For example, during story discussions a team discovers that certain items are required to meet the customer's needs and those discovery points become requirements. Some requirements may be internal rather than external. In other words, development may be involved to create the new feature. The existing application code may need to be enhanced to accommodate the change and frequently that involves significant design considerations and implications. Discussing intricate details and integration points is valuable in discovering all the changes needed to create a working, high-quality application feature.

Story mapping is effective because it offers active discussion and visualization of steps, stories and requirements. A development team can literally build out a full map of a project. The discussion and map building among team members and stakeholders benefits all because it educates and provides an overall layout of the current and planned application functionality. Users and developers know where the software needs to go and what is expected. Additionally, story mapping allows a development team to envision the features or items existing in their backlog. By knowing more fully what's in the backlog, a team can better judge item priorities while considering the full workload.

Story mapping also allows team members to jot down all their thoughts and ideas. Once you get it on the map, it's out there and available for discussion and consideration. The more ideas on the board, the less you have to remember. Story maps are easier to update and revise as the need arises. Because the discussions can occur at any time, all the updating can be done individually or within the group meeting. All stakeholders have access to the story map and can add and update sticky notes. In most tools, all actions are tracked so the full history is always available. Finally, story maps keep all stakeholders in synch, from customers to developers, architects, testers and any other group involved. Customers understand the full picture and are more able to describe what they need while code is still in development and easier to change.

Gathering requirements: Role of the scrum master

The role of the scrum master in gathering requirements is not to be a personnel manager but rather the supporter who handles outside distractions or external complications that need to be fixed for the team to make progress. The scrum master is also involved in translating product owners' and customers' needs, keeping the team focused on discovery and communication rather than the day-to-day removal of obstacles. In many ways, a scrum master is similar to a liaison between the needs of the consumer or customer and effective, valuable communication with development resources -- thereby influencing the design and quality of the final product.

Scrum masters are often described as servant leaders because they enforce scrum policies but at the same time keep the team focused on application design and improving team communication and performance. Scrum masters need to be more than cheerleaders or scrum aficionados -- they must actively keep the team moving forward while keeping them on track.

Gathering requirements: Tools

As for every process, tools are available to assist. Bauer provides a JIRA plug-in tool for visual presentation and editing of story maps. In this tool, there is no paging or tedious reloading. Users can drag and drop items easily to visualize and build maps.

Lino also offers a useful visual tool that uses sticky notes to communicate story maps. It simulates the physical story mapping board for teams with distributed or remote members. Users can effectively create, view and participate actively and easily in story mapping discussions. Lino is visually appealing and accessible from any browser using a computer or mobile device.

Two more collaborative tools for creating story maps are cardboardit and featuremap. Both are virtual tools for sharing and using sticky notes to plan and gather user stories and requirements.

Next Steps

Listen to this podcast to learn how to make Scrum implementation work


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

One more suggestion i would add is to establish a "three amigos" approach (with a product owner, a programmer and a tester) and get them all together early in the discovery process. The tester can provide valuable information up front in the way of asking questions and provoking discussion about understandings and expectations. early engagement makes the big difference.

Where the Product Owner is a customer, giving them access to the supplier SaaS tool provides an effective solution for User Story collaboration
Some techniques I've heard you could use is inspired by Damian Syandion's Improv(e) Your Testing talk.

1. For every test idea, repeat it, and then think of one more thing that adds to that idea.
2. Consider your Environment.
3. For every positive requirement, say it, followed by, yes, but.... what ways could it go wrong.

Lots of good tips here. I'm curious, has anyone ever been on a team where requirements discovery/story mapping has become too time consuming, to the point that if everyone is included, it becomes difficult to get other work done on a regular basis?

My current team typically does not work on large projects, but rather lots of little projects, and usually more than one project concurrently. It can get to the point that so much time is spent planning that people dread it.
Yes, I'm in the same boat

"...customers, product owners, testers and the development team (all available stakeholders..."
In some organizations there are many additional stakeholders: trainers; managers; supervisors; help desk technicians; security, documentation, operations, deployment, marketing, DBA staffs; maintenance programmers....