Guaranteed Requirements Gathering Techniques for Agile Teams

Guaranteed Requirements Gathering Techniques for Agile Teams

Have you ever had a requirement that was so vague it almost seemed pointless? And the team had to do all sorts of work trying to figure out what it meant. At other times, though, a requirement is so lengthy and specific it’s like reading a textbook.

When gathering requirements is done well, it leads to a fruitful project. Everyone has clarity on the end goal and the client ultimately is satisfied.

But it’s hard to find the right balance between making requirements too dictatorial or too flimsy.

And there’s all sorts of challenges to gathering them. If there’s not equal contribution from all stakeholders, they end up being too business oriented or too tech oriented and they don’t consider the end user.

The point of a requirement gathering session is to unlock the power of the team. It’s about combining everyone’s expertise, and then brainstorming around the project goals. Finding the right requirement gathering technique is key. It allows each person to equally contribute their insight, and the team is able to create a thorough list of requirements with the right balance of specificity and openness.

Let’s consider the characteristics of good requirements in agile, the various types of requirements a team needs for a project and then explore some methods for gathering requirements.

Requirements in Agile

When a team gets excited about an idea, it’s easy to jump right into the design phase. However, without a good plan in place they’ll probably find themselves backtracking over and over again.

Gathering requirements is about developing a good understanding of what the job is before you break ground. It defines the scope of the project, and clarifies to all the stakeholders what the project is working toward.

• Benefits of Requirements

  Taking the time to gather requirements gives the team a clear idea of where they’re headed, so they save time and money by not going down any rabbit holes.

  Additionally, the development team is able to quickly move past the discovery phase and into design and development. And creating good requirements leads to the best possible product for the client.

• Agile Requirements

  One of the principles in the Agile Manifesto states: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s advantage.”

  There was a time when requirements were presented like a textbook for the team to follow, and the objective was simply to read the instructions and get the job done.

  In agile, however, the orientation is on providing a valuable product to the customer. This entails having an ongoing conversation with the customer and updating requirements throughout the project. First and foremost, the requirements consider the client’s overall objective; they’re not focused around simply fulfilling a list of specifications.

• Characteristics of Good Requirements

  Two areas to focus on when developing requirements are the project goals and tech stack. The goal, at the beginning stage, is defined as the problem you’re trying to solve. Usually, it’s not a specific feature at this point. When the team brings together its collective knowledge and skill set, they’re able to determine which coding frameworks and languages would bring about the best possible user-friendly product.

  A requirement quickly and effectively communicates its acceptance criteria. They say that a picture tells a thousand words, and this is so true in the case of requirements. Oftentimes, by including a photo with the requirement in lieu of text, everyone understands exactly what is expected of them.

4 Phases for Gathering Requirements

As discussed, requirements in agile are never set in stone. Collecting and revising requirements continues until the project’s completion.

However, taking a thorough approach to gathering requirements at the project’s beginning establishes a strong foundation. Here are four key phases a team goes through in order to gather a comprehensive list of requirements.

1. Preparation Phase

   The preparation phase is about learning the basics. The team researches the client and their industry. It researches similar products already on the market, and understands their features.

   The team looks at what the client has already outlined as requirements and brainstorms any questions they have around it.

   They prepare for a meeting with the client by assigning everyone roles, including note taker, moderator and interviewer.

2. Gathering Phase

   The gathering phase entails speaking closely with the client to further understand their perspective and the product goals. Meeting in person is ideal, as it creates a space for everyone to share, and eliminates misunderstandings.

   Develop further clarity around the product goals by asking how the client came up with the idea. This session isn’t always about finding clarity around a specific feature, but more about understanding the desired outcome.

   Determine the project’s budget, scope and timeline. Also, come to a deeper understanding of the company and its structure, and identify a contact person for the team. Create some protocol around changing requirements.

   Documenting everything makes it easy to reference this information later on in the project.

3. Follow-up

   When all the requirements have been gathered and documented, communicate them to all project stakeholders. Finding agreement around the priorities and goals allows the team to move into the design and development phases.

4. Revisit

   Finally, the team is committed to continually re-visiting the requirements. At the end of each iteration, the increment is shared with the client for feedback. Depending on how the process is going, the requirements may, and probably will, change from time to time.

   Updating requirements entails gaining approval from the client’s contact, then coming to an agreement around budget and timeline changes.

   As you can see, gathering requirements is an ongoing process. Properly setting the stage at the beginning of a project ensures that the goals are clear and that upcoming changes take place easily.

3 Classifications of Requirements

Requirements need to be thorough, meaning they represent all the facets of a project. When they’re too siloed, it creates blindspots. For example, requirements that are tech-heavy may not really address user needs. A majority of business-oriented requirements may not delve into the technical capacity of the team.

Requirements generally are grouped into three key areas: business, user and technology. Let’s look at the characteristics of each of these.

• Business Requirements

  Business requirements clarify questions such as: Why would a customer buy the product? What problem does it aim to solve? How does the company plan to earn revenue with the product?

  Addressing the business side of a project entails having a keen understanding of the client’s industry, and the competitive advantage they offer.

• User Requirements

  User requirements focus around the customer experience. The aim is to find a solution that entices the customer, is easy to use and that serves a needs not formerly found on the market. These requirements are similar to business requirements, but they’re focused entirely on the user.

  The expertise of the product manager is essential in creating these requirements, as they’ve researched the market and understand the customer and his or her problems.

• Technical Requirements

  Technical requirements look at things like the backhand functionality of the product, its features and the platform where it’s developed.

  The client may not understand everything about the technical aspect of the product and so visuals are oftentimes helpful here. By effectively communicating all the features the client wants on the product, the development team is able to come up with a tech stack that best serves the customer’s objective.

  In sum, a project has a rounded approach when it creates business, user and technical requirements. This means carefully considering the project from all angles, which in turn leads to a well-developed product.

4 Requirements Gathering Techniques

Once you’ve completed the preparation phase and have developed a good idea about the client and their vision, it’s time to gather requirements from all stakeholders. An in-person meeting is the ideal context for gathering requirements. But it’s still possible for remote teams.

Here are four approaches for gathering requirements.

1. User Story Creation Session

One method for gathering requirements entails having all the stakeholders gather together and each individually contribute requirement ideas in the shape of user stories.

Each stakeholder, including the development team, the client, the product manager, the project manager and ideally a customer, contribute as many ideas as they can come up with. The user story format assures that the requirements are oriented around the end goal.

These requirements are added to the product backlog. At this stage, many of them will be quite large. The product owner reviews and prioritizes them according to the product goal, and the team collectively decomposes the stories and organizes them into features and themes, and eventually items small enough to be included in a single sprint.

2. Solo Requirement Creation Before Collaboration

Each stakeholder in a project has a particular area of expertise, and another area they know very little about. For example, a developer has a sophisticated understanding of the technological possibilities of the product, but may have a poor understanding of the market and the customer.

On the other hand, the product manager is usually the opposite. They have thoroughly researched the customer and the market, and know just what sort of products would suit their needs. However, their technological knowledge is limited.

And so various stakeholders, naturally, focus requirements around their area of expertise.

When a team isn’t able to meet in person to gather requirements, then another effective method is to communicate the basic project goals to everyone. Then, each stakeholder individually writes whatever requirements they think of. Later, these requirements are presented to other team members, perhaps in a video conference platform, for others to provide feedback and further refine the requirements.

For example, the project manager would outline basic issues related to scope, budget and timeline, while the client and product manager requirements would be more focused around user and business requirements. The development and engineering teams outline mostly technical requirements.

The objective is to reap the benefits of each persons’ expertise. At the same, it’s important that each requirement complements the others, and so the secondary meeting is instrumental in rounding out the list of requirements.

3. 9-Step Brainstorming Session

This method for gathering requirements is courtesy of Agile Coach Scott Killan. It’s a fun exercise that draws on the power of anonymity and continual brainstorming to unleash the power of a team. It’s a highly collaborative, yet structured process for generating a thorough list of requirements.

One great feature of this technique is that it’s versatile; it works for groups as large as seventy and as small as six. It has nine distinct steps and each can be time-boxed to suit your time frame.

This method must be in-person, and it works especially well when it includes a variety of stakeholders, including customers.

• Prep Work
  Find a room with smooth walls and tables and chairs. Ideally, have a projector in the front of the room to broadcast the goals to the whole group. Send an email to all participants beforehand, outlining the objectives of the session.

• Supplies
  For this activity you’ll need sharpie marking pens, small stickers with red dots, and 3×5 sticky notes, some yellow and some another color.

The 9 Steps:

1. Introduce the Idea

   Introduce the project and any key stakeholders. Clarify the overall project objective (not specific features), then provide examples. Ask the audience to give ideas of other examples.

2. Brainstorm Requirements

   With a good understanding of the project and its objectives, everyone uses the sticky notes to write down as many requirements as they can think of, using one sticky note per idea. The facilitator collects these as they are written, in random order. This way, no one knows who wrote the idea.

3. Announce All Requirements

   When all the requirements have been collected, the leader and an assistant read them aloud to the room alternately. As they read the ideas, they place them onto the wall in random places around the room. If people come up with additional ideas, they write these down and bring them to the leader.

4. Categorize Requirements

   The next step involves categorizing the requirements. Working in groups of 2 to 4, the group mingles and rearranges the requirements into various categories. This usually generates a lot of enthusiasm as people mill around and discuss. People can continue to add requirements at this stage.

5. Label Each Topic

   The second color of sticky notes comes out at this stage. Continuing to work in small groups, each category receives a label. People may choose to work around a category that most interests them, such as quality assurance or testing.

6. Simplify and Clarify

   At this step, everyone looks through all of the requirements and removes duplicates by wadding up the piece of paper and throwing them across the room. This is where things start to get fun (and a bit messy)!

   If two requirements sound the same but really represent two distinct ideas, they’re re-written to clarify the meaning more precisely.

7. Prioritize Categories and Requirements

   The small groups prioritize the requirements in each category, and the most important categories are identified as well.

8. Discuss the Top Three Items

   At this point, people return to their tables to discuss the top three requirements in each category. This keeps everyone thinking and brainstorming around the most important topics.

9. Vote on the Best Requirements

   As a final step, everyone goes around the room and votes on the most important requirement per category. Some surprising winners may emerge: even the fourth requirement sometimes ends up receiving the most votes.

   And so that’s a summary of a requirements gathering exercise. The anonymity of this project is a great strength, as it levels the playing field and everyone’s contribution has equal weight. Additionally, everyone leaves with a good understanding of the project, and they’re focused around the most important requirements. The sticky notes can be used to form the product backlog.

   At the same time, this activity has its limitations in that it must be in-person, and the coverage of requirements, though broad, is somewhat superficial. There isn’t any drilling down on one concept. This fine tuning would occur at a later meeting.

4. Storyboarding

A picture oftentimes says more than what ten pages of text could communicate. Visual learners especially benefit from the storyboarding technique for gathering requirements.

With this requirements gathering technique, the team draws images of the final product, and the stakeholders and the client contribute suggestions and ideas.

The pictures include all the product’s basic requirements. If the team is developing an e-commerce store, for example, they’d present images of the sign-in page, the individual listing page, the cart and checkout.

This method is helpful for people who don’t have a lot of technical knowledge; they’re able to still offer advice and ideas.

Including an image of the end user is a strong reminder to keep the final product user-focused as the team develops all the specifications.

And so there are some ideas for gathering requirements. When determining what method works for your team, consider its size, the dynamic on the team and the various learning styles of those involved.