Requirements Gathering in Agile

Agile development practices have changed requirements gathering into a more “continuous” process rather than a step that is completed prior to beginning a project, according to expert Scott Sehlhorst.

What are the latest tools and techniques for requirements gathering? Do you see any emerging trends?

There are a couple recent changes in requirements gathering in recent years -- the first is a change in when requirements are gathered, the second is a change to tap into some more effective collaboration and brainstorming techniques.

Historically, requirements were gathered before the engineering work for the project was started. These requirements were then thrown over the wall, and the team worked to build a product that addressed the originally identified needs. As Agile development practices propagate through organizations, the benefits of getting "continuous" feedback are becoming apparent beyond the development teams. This is leading to organizations recognizing the opportunity to continue gathering requirements throughout the process -- refining, clarifying, and discovering new requirements. Markets are constantly changing -- customer expectations are changing as customers’ original needs are met and perceptions are changed. Solutions that you and your competitors introduce reveal the problems that were hiding behind previous identified problems (and therefore enabling new requirements to emerge). Advances in technology in adjacent markets also influence customer expectations by causing them to imagine that previously "unrealistic to solve" problems become front of mind for your customers.

I prefer to think of it as requirements discovery rather than requirements gathering. The process is more like an Easter egg hunt than collecting sea shells on a beach. Requirements are there, but rarely are they obvious. People are rarely good at directly describing the problems that are important for them to solve -- people tend to talk about possible solutions (that they invent) that they (without telling you) believe will solve their problems. You have to find out why someone wants widget X - to solve problem Y. Once you identify problem Y you can then decide if widget X or service Z is the best thing you can create to solve their problem.

When your company's development process is changed to one of incremental development, it allows your team to practice continuous improvement of your product -- each cycle can provide an improved version of your product. When you gather requirements continuously, in parallel with this development, you have the opportunity to infuse this additional learning into the cadence of product delivery. If you don't keep gathering requirements, you waste this opportunity, and your team is left with no option but to continue building yesterday's product -- the one you defined before the project began.

Elicitation techniques used to center on customer interviews and surveys, focus groups and ethnographic research. Ethnographic research -- discovering the problems people are trying to solve by watching them try to solve them -- is still very powerful and rarely done (because it is difficult and expensive). Focus groups, surveys and interviews are still important -- what's changing is how the elicitation process is performed. Researchers have realized that asking the "easy to ask" questions yield answers of suspect value. The refinements today are coming from changing the nature of the interview from an "assay the situation" approach to a "get people to play games that yield insights" approach. These innovation games (there's even a company by that name) tap into cognitive cycles that are more effective at exposing underlying needs (problem Y). This reduces the risk of focusing on widget X.

One example of these different approaches is a game called "Buy a Feature" that is described in the book, Innovation Games: Creating Breakthrough Products Through Collaborative Play, by Luke Hohmann. In this game, the group of customers (focus group) is tasked with collaborating to "buy" features (widgets) from a pool of possibilities (provided by you) using a constrained resource. It is the collaboration process between members of the focus group around how to spend the limited "funds" that identifies the underlying problems -- as members of the group explain to each other why they want each widget. The list of purchased widgets is not the important output of this elicitation exercise -- it is the conversations that happen as focus group members (players of the game) negotiate to reach consensus.