7 techniques for better Agile requirements gathering
Avoid headaches when you gather software requirements. Learn these seven Agile techniques to understand requirements without reverting to Waterfall.
Agile overhauled requirements gathering. Under the Waterfall model, development teams gather software requirements before coding or testing. But Agile radically changes the rules for software requirements.
Agile requirements gathering is a practice teams often perform on the fly. For example, developers update requirements between iterations -- if the software project has documented requirements at all. Some Agile practice purists balk at the word requirements. A lack of requirements could throw many business or technical processes into chaos, but Agile development thrives in an iterative approach. Agile trades certainty for adaptability.
Let's look at the goals of Agile software development and practices that help requirements gathering keep pace.
Why requirements gathering matters
Requirements set project goals and guide developers through coding and testing. Wrong or incomplete requirements can create project delays, cost overruns and poor user acceptance or adoption -- even project failure.
What makes Agile requirements gathering unique? Traditional Waterfall projects emphasize upfront gathering, review and approval of detailed requirements. Approved requirements are unlikely to change. Change requests are often costly and disruptive. This requirements paradigm simply isn't flexible enough to work in Agile development environments.
Agile and other forms of continuous development depend on fast, iterative, customer-focused processes. The scope still defines the project's purpose, but these secluded requirements teams must rethink how they approach their work. They must determine what users actually want in a software product.
Developers should embrace a fast, flexible and dynamic approach to software creation. They can experiment, try new things and evolve a product that is more competitive and higher quality than one created with a gated development approach.
What does the Agile Manifesto say? The Agile Manifesto highlights four fundamental differences between Agile and Waterfall development:
- Individuals and interactions over processes and tools;
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation; and
- Responding to change over following a plan.
These four values mean Agile development -- and, thus, Agile requirements gathering -- supports the evolution of a final product that best addresses user needs and business goals.
What role do user stories play? The user story represents requirements in a simple written narrative told from the user's perspective, rather than a comprehensive document.
User stories enable developers to estimate and plan work. User stories change and mature throughout the software development lifecycle.
Developers compile the many user stories into a product backlog. The product manager or product owner manages this backlog.
7 ways to improve Agile requirements gathering
While Agile is a powerful development paradigm, some practitioners find Agile requirements gathering chaotic. Try these ways to bolster requirements gathering.
1. Supplement user stories. User stories don't always include enough information for development decisions. Complex or mission-critical projects especially demand more detail.
Some projects must have documentation to meet compliance or process standards. In these cases, development teams can supplement user stories with relevant details, such as use cases and decision tables.
2. Involve stakeholders regularly. Developers can face enormous challenges when they're isolated from project stakeholders, such as users and product owners. Too often, stakeholders get involved early, but don't see the results of the work until late in the project.
Projects can fail when stakeholders and developers fail to communicate. Stakeholders are the experts in a project's requirements. They should share ideas, make suggestions and model and document requirements in each iteration. Developers can then build and adjust the product accordingly. Project and product owners generally prioritize those requirements for developers.
Reconsider the project if the development team cannot identify appropriate stakeholders, or if those stakeholders don't take an active role.
3. Prioritize requirements. Once a requirement is outlined, developers estimate the time and money necessary to implement the feature or functionality. The list of requirements and estimates for the iteration can take shape as a stack of index cards, or some other method. Due to time and budget limitations, not all requirements make it into a given iteration.
A project or product owner works with developers to prioritize the list of requirements. They sort the stack into high- or low-priority work items for the available time and budget. Generally, the higher priority the requirement, the more detailed the item should be. Development teams often shelve low-priority requirements for future iterations, though it is possible to add or remove items from the list at any time.
4. Focus on executable requirements. Agile teams typically model requirements, write code, and then refine and refactor it to implement those models. This process is called test-first design. Modeling translates requirements into code. Executable requirements focus on what something needs to do, and how that thing should work. When developers work through executable models upfront, they can identify cross-requirement dependencies. Developers can also spot potential problems via highly focused approaches, such as test-driven development.
5. Use the INVEST principle. User stories are easy to create. Good user stories are harder to create. To write valuable user stories, Agile teams often use the INVEST mnemonic:
- Independent: Each user story should stand on its own, independent from other stories.
- Negotiable: Stories are not contracts, rather opportunities for negotiation and change.
- Valuable: Every story should add value for users and stakeholders.
- Estimable: Every story's time and budget costs should be calculable, based on domain and technical knowledge.
- Small: User stories should be small enough to estimate and implement simply.
- Testable: Make sure you can test the user story through criteria the story itself explains.
6. Think layers, not slices. With Agile requirements, it's helpful to think small. Smaller requirements and feature sets correspond to user stories that are easier to estimate, prioritize and build. Larger, more complex requirements tend to create dependencies, going against the INVEST principle.
Compose user stories with an eye toward the software stack, such as the front end, middleware, back end and database.
7. Prototype and update. Agile development paradigms facilitate developer experimentation, while mitigating risk through tests. Prototyping is a useful practice to test ideas and encourage discussion with stakeholders. Developers can update the prototype to refine the software and solidify its design. The resulting code often is usable for the build.
