Requirements gathering: Collaborative approaches for software teams

Agile expert Lisa Crispin shares real-world examples of ways teams can collaborate, creating a shared understanding between business and customers and IT development teams.

Requirements churn is an issue for just about every software team I’ve known, Agile or not. Often, it takes way too long to create the specifications, which turn out to be wrong anyway. There’s no magic solution to getting “just enough” requirements at the right time. Each team must experiment to find ways to improve the requirements process a little bit with each iteration. We’ll explore some collaborative practices that have helped many Agile teams succeed with getting the right requirements and minimizing the churn.

Shared understanding

Constant communication between the development team and business experts is key to ensuring that everyone understands the purpose of the software being created. I recall a Waterfall project where my team proudly delivered a new application, only to learn the stakeholders’ top priority was fast response time. Our application was slow-performing, and thus totally useless to the business. If we’d taken the time to understand the product vision that disaster could have been avoided.

My current team kicks off major new themes or projects with one or more “brainstorming” meetings, each time-boxed to one hour. The product owner starts a discussion of each feature by explaining the problem that the business is trying to solve, or the value they hope to obtain. He gives examples of user scenarios, and draws workflows and examples on the white board. He and other stakeholders answer questions. We often mind map complex features, or conduct a story mapping exercise. Visualizing the features this way often leads us to simpler, less expensive ways to implement solutions.

A few days prior to each new iteration, we hold a “pre-planning” meeting to go over the stories for the upcoming sprint with the product owner. During this meeting, we write high-level specifications and test cases for each user story on the white board, along with questions that come up. This way we arrive at a collective understanding of each user story’s requirements, and hopefully get our questions answered before we start work on it. We focus on the primary business value for each story and look for ways to cut out costly “extras.”

Jonathan Cogley, CEO of Thycotic Software, told me that his development team can usually “rattle off the next five major things that customers need at any point in time just from memory.” He explains, “This is a result of lots of communication with our customers daily.”

Zeroing in on what the customers really want isn’t a random process. We have to learn to ask the right questions. Business analysts and testers are good at asking questions that elicit helpful examples of desired system behavior. My team is currently learning more about Agile analysis techniques such as structured conversations so we can help stakeholders define business rules in a timely manner.

Try different approaches to helping the development team understand the business experts’ vision at the start of a new project. Find ways to communicate on a daily basis to ensure that work in progress is in line with business goals.


Customers tend to want everything, right now. We help them prioritize by asking questions such as, “What do you want to see at the next demo?” It’s our job to help them understand that getting, say, 80% of desired features working and ready to use by the business deadline is better than getting all of the features 80% done, and thus not usable, by the deadline.

Companies used to working with huge requirements documents find it hard to learn how to slice their features into small increments that can be completed in a few days. Experiment with different techniques to see what works best. My team works together with the stakeholders to represent desired functionality visually, with a story map, mind map or flow diagrams on the white board. Then we start identifying end-to-end thin slices and turning them into user stories. The development team understands the risks and dependencies, and the customer team understands the business priorities.

Some companies plan a road map of upcoming features for the next month or quarter, or even longer. One approach is to maintain a portfolio of prioritized features that teams can pull in as their workload allows.

My company has found that priorities shift so fast, it doesn’t make sense to plan ahead more than one or two sprints, except in a general way. Other companies need to plan further into the future. Scott Wesson, senior vice president and CIO of UDR, said that in his company, if they don’t plan ahead for multiple quarters, they feel like they’re always in firefighting mode. He says executives need to understand shifting priorities and adjust the plan. “Plans are plans and it is ok to adjust a plan based on new information. If we hold hard and fast to a plan just for the sake of it, we will fail. We have to adapt and be willing to cancel something altogether.”

The business must juggle priorities from different stakeholders. In Jonathan Cogley’s company as well as my own, features needed for future sales deals as well as technical support issues drive their road map. Someone in a role such as product owner can help coordinate diverging business priorities. Development team members that understand the business domain as well as the technical implementation can help mitigate risks.

Driving coding with tests

Understanding the business needs at a high level is the essential first step, but

once we’ve identified user stories to develop, how do we get the details right? The practice of driving development with business-facing tests is key. Some people call this acceptance test-driven development (ATDD), some call it Specification by Example (SBE). We get examples of desired behavior from business experts, turn those into executable tests, and write the code that makes those tests pass. Once they do, we have living documentation that provides a safety net for future development.

The testing and coding for each user story is a process of many tiny increments of testing, coding and more testing until all the tests are written and passing. Try slicing each user story into smaller threads and pair with your customer to look at each slice. Demos done early and often allow small adjustments that ensure the story meets customer expectations.

Documenting requirements

The shared understanding a team acquires by communicating continually with business experts is the best foundation for delivering what customers want. But we also need to capture enough details. We can digitize pictures of white board drawings, paper prototypes, story maps and mind maps. My team stores these on a wiki, a collaborative tool which is easy to update. The wiki also documents high-level functional requirements and test cases, along with extra-functional requirements such as security, usability and performance. There are many lightweight, collaborative tools available to manage requirements.

The details of functional specifications will be captured in the customer-facing executable test that guide coding, the “living documentation” that will always be up-to-date since the tests must pass continually in the continuous integration process. These knowledge bases are invaluable, but don’t replace the need for daily communication and pairing between the development and customer teams. Keep looking for more and better ways to collaborate with business experts.

Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.

Dig Deeper on Topics Archive