The way we elicit requirements is changing as our applications become more complex and our teams become more Agile. In part one
SSQ: There are many different tools and techniques for eliciting requirements. Do you have specific recommendations?
Gottesdiener: In the book that Mary Gorman and I are writing on Agile analysis and planning, we use the metaphor of “structured conversations” to describe this work. It’s a fluid, rapid, yet comprehensive process that incorporates elicitation, analysis, specification and validation. There are a variety of ways to structure this conversation. We like to use an explore-and-evaluate technique in lightweight facilitated grooming workshops. Stakeholders collaboratively identify timely product options (this is the “explore” part), assess the options and identify the highest-valued ones (this is the “evaluate” part), and then slice each backlog item based on value. They then identify clear, unambiguous acceptance criteria for those thin slices of requirements.
As you explore requirements options, you employ snippets of lightweight analysis models such as sketches, portions of a data model or state diagram, a context diagram, and examples, which will become acceptance tests. You focus only on the immediate requirements (backlog items) you need to prepare for the current or next delivery cycle. A key goal for the structured conversation is to gain a shared understanding of the requirements -- an understanding that incorporates the voices of the business, customer, and technical stakeholders. In fact, structured conversations are powerful whether you use Agile practices or more traditional ones.
It’s important to adapt whichever analysis models you use to the specific product domain. User stories -- which are wonderful for many transition-oriented domains -- only go so far for data-centric domains such as business intelligence projects. You need to be sure to elicit other dimensions such as data, controls (business rules), interfaces, and quality attributes.
SSQ: I see in upcoming workshops at STARWEST and Agile 2011 you will be co-leading a session with Janet Gregory titled, Agile Requirements Exploration with Tester Collaboration. Why do you think testers should be involved in requirements elicitation? Isn’t that traditionally the role of the Business Analyst or Product Owner?
Gottesdiener: Agile practices, when done well, focus on delivering value and provide the freedom for the team to collaborate toward that shared end. As Mary Gorman and I have been saying, “it’s the goal, not the role.” By that, we mean that teams need to focus on delivering value each and every day, and not on who does what.
I believe that there is a lot of cross-fertilization benefit to be gained when people with skills in different disciplines collaborate closely toward shared ends. This is very true for the disciplines of testing and business analysis. The tester mind-set is crucial for verifying requirements. The business analysis mind-set is crucial for validating requirements.
I’m thrilled to be collaborating with Janet on this session at STARWEST and at AGILE 2011. By incorporating analysis practices into the testing discipline and testing practices into analysis, we collapse the traditional “V” model of verification and validation. This enables development teams to more efficiently and effectively identify the right requirements, and get the requirements right.
SSQ: If there are too many people involved in requirements elicitation with different opinions and priorities, won’t it confuse and delay the process? Who makes the final decisions?
Gottesdiener: Successful products and solutions balance the collective perspectives of three diverse stakeholder communities: business, customer and technical. This holds true, in my experience, for internal products as well as commercial products. It’s essential to engage people from all those communities, forming a partnership with the shared goal of delivering a high-value product. This isn’t about making people feel good -- although that is a side benefit. Rather, experience tells us it’s the very best way to build the right product at the right time.
It starts with analyzing your stakeholders and identifying how they -- or their voices -- will be engaged from discovery through to deployment. Because there could potentially be a large number of people, you want to select a representative set. Be transparent about who is representing which stakeholder voices.
When it comes to decision making, project teams need clear decision rules and decision-making processes. When I work with teams, Agile and otherwise, I begin with helping them create working agreements that include explicitly identifying what decisions will be made, what our decision rules are, and what process we’ll use to make decisions. By collaborating using lightweight yet holistic practices, you strengthen and streamline the decision-making process.
It’s true that decisions about which requirements will be delivered and when are made primarily by the product owner or product champion, but there may be other requirements-related decisions that are made by other stakeholders. For example, the lead architect may make decisions about nonfunctional requirements such as design and implementation constraints. The key is to be open, clear, and unambiguous about decision making.
After all, product development and delivery is really about making continual, evolving requirements decisions.
SSQ: If you could give one piece of advice to a team who is working on improving their requirements processes, what would it be?
Gottesdiener: Stop. By that I mean: pause and reflect. Frankly evaluate your requirements process and products -- what we call “retrospecting.” Genuinely seek to learn from your colleagues and customers. Use both tangible and intangible data as input to your retrospective. With an open mind and heart, listen and learn from feedback. Collaborate to agree on small adjustments, make them, and repeat. Retrospect again and again. Individually, and as a team, commit to continual learning and improvement, and “make it so.”