As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time.
Agile requirements need to be understood in context of the product, release, and iteration
Consider iterations, a key attribute of agile projects. How can you usefully define an iteration without developing some requirements? At what point in your project will you realize, retrospectively, that the rework involved in refactoring your architecture outweighs the time it would have taken for you to understand the big picture—something you get when you do requirements right?
I work with clients adopting agile practices. One of the greatest challenges is scaling agile practices when you’re building and enhancing large, complex software products. This issue surfaces early in a project, when the team has to decide which slice of the application to build for the first iteration.
In complex products, a good approach is to exploit one of agile’s greatest strengths: the imperative to reduce risk and increase learning as soon as possible. By building a small slice of the product and getting feedback on it immediately, teams quickly and inexpensively expose technical unknowns, while customers discover and explore true needs (requirements).
Balancing Business and Technical Value
But just jumping into building a slice the application can be risky in and of itself. How do you know where to start? The customer may believe there is a great need for certain user requirements to be satisfied, and indeed there may be. Some teams discover that, depending on the product, you can’t fully satisfy some user requirements until you build a subset of nonfunctional requirements or set up a technical infrastructure.
Another phenomenon on large projects with multiple teams is the discovery, after “sprinting” (e.g., iterating) two or three times, that the different teams need the big picture to better coordinate their work.
Iterate-Inspect-Adapt
Agile teams deliver business value, reduce risk, and manage changing requirements by chunking product delivery into iterations. Each iteration delivers working software. This is not a new idea in software or product development, but it is becoming a mainstream practice thanks to agile methods.
Each iteration is a fixed timeframe of several weeks (more or less) encapsulating activities to build a slice of working software. The product owner selects a subset of requirements to build in this iteration based on their business value.
Next, the team holds an iteration planning workshop to estimate the tasks and time it will take to deliver the software, identifies risk mitigation tasks, and defines “doneness” for the iteration. During that iteration, the team cycles through the activities of define-design-test-develop-deliver.
The inspect portion of the iteration is a demonstration of the software (more about that in a minute). The inspection ends the iteration with its beginning in mind. The team adapts its process by holding a retrospective sssion, which ends the iteration with the next beginning in mind.
Playing Around
Building prototypes and holding demonstrations are elementary to agile teams. During a demonstration, developers show the working software for each story. Occasionally the demonstration itself can generate new stories. On an agile team I was working with, a known problem with the test platform became unavailable during a demonstration, raising the need to create an infrastructure story to build a stable test platform.
On an agile project, this work is often done just in time. The business analyst and product owner work-ahead: during the prior iteration they flesh out the stories and related requirements for the next iteration.
In addition to prototypes, they might supplement a story with storyboards (using tools such as whiteboards, posters, and informal sketches), business rules, and user acceptance tests. This work-ahead is essential for agile teams to do in order to establish and retain a successful pattern of continual delivery.
The trick is balancing business need with technical feasibility.
An effective solution is to hold a series of interlocking workshops to deliver requirements-driven roadmaps and product plans. These workshops work on three levels: product, release, and iteration. They involve the project community—the technical team and the business customers (product owners). This is illustrated here.
Product Workshop
Start with a product workshop to define your vision, the project scope, and a product roadmap. In this workshop you define which product features you will release over time. This workshop is done once for the product and serves as a guidepost for subsequent releases and iterations.
Identify the vision you have for the product, documenting it in a vision statement, a product “box,” or a metaphor. From there, define product scope using scope-level analysis models such as a context diagram, a list of events, conceptual entities, or a list of features in and out of scope.
Then, armed with this high-level understanding of the product, you create a product roadmap that reflects both a wide and a narrow view of the requirements that are needed to satisfy the product vision over time.
To create your product roadmap, group your scope-level requirements into feature categories (e.g., ordering, reporting, performance, etc.). Then analyze their interdependencies and their business value. Many teams do this by writing high level stories (i.e., epics) on cards and arraying them on the wall. Some teams use high-level use cases (i.e., named user goals, each with a one or two sentence description). The team needs to decide which portions of which features will be delivered in each release and determine a release schedule (perhaps two to four months).
Your goal is to gain understanding of the big picture—as a project community. Define the scope at a high level, using analysis models. Build your roadmap in a collaborative fashion, bringing together the product owners (business stakeholders) and the delivery team (technical stakeholders). I like using workshops as the venue for making this happen.
Release Workshops
For each release, create a release plan to define what will be delivered for a release. Each release will implement a subset of features, taking into account both business need and architectural dependency.
Releases tend to last three to six months and incorporate three to six iterations. Any given release plan is based on your understanding of requirements at this early point. You will need to conduct this release planning workshop for each release, roughly every two to four months for large products.
A requirements-driven release plan includes scenarios or stories (or lightweight use cases), a first-cut data model, quality attributes or quality attribute stories, and perhaps personas or actors.
To understand dependencies, you can use pre- and post-conditions on events (or scenarios), allowing you to sequence the functionality of your iterations appropriately. Your context diagram should be used to define interfaces that need to be built into a release.
Iteration Workshops
Each iteration starts with an iteration planning workshop in which the team decides what requirements from the requirements backlog to deliver in the iteration - given team capacity, risks, and product development status. The iteration planning session also incorporates feedback from the prior iteration’s demo and retrospective.
Your iteration planning workshop includes documentation of user requirements (such as stories or scenarios), quality attribute stories or story “doneness” expressed as quality attributes, integration stories, and any technology or tool-related tasks that need to be completed. Some stories will need to “right-sized” and re-prioritized during the workshop.
After each iteration planning workshop, the team holds one or more informal requirements workshops to develop requirements for the current iteration. These workshops focus only on the requirements for the current iteration. They may be very informal (such as whiteboard or flipchart modeling sessions), or more formal and require pre-planning (such as when multiple product owners or members of other related teams must be present).
Outside the workshop, a business analyst or product owner should start requirements exploration for the next iteration (working one iteration in advance, to jump-start the next iteration planning workshop) while also supporting requirements definition and testing in the current iteration.
Recurring Retrospectives
An essential element of all these workshops are retrospectives. These workshops give you feedback on both the work product and the team process.
Remember: you’re not doing agile unless you’re doing retrospectives!
And even if you’re not currently using agile approaches, retrospectives are an essential tool for any business and technical professional.
Requirements Matter
Agile projects can't abandon requirements development and management. Agile projects need requirements. A requirements-driven—albeit lightweight—approach to large agile projects saves time and money and accelerates the team’s ability to deliver the right product, sooner.
Agile on large, complex products means you develop the necessary level of requirements to meet the needs of the successive level of stakeholders. Each level delivers what is useful to the next level – and not more. In this way, you lighten and tighten requirements development to fit the rhythm of agile delivery, in context of, product, release, and iteration.
References: Ellen Gottesdiener, "Developing Requirements in Agile Projects," Modern Analyst, May 2008.
Copyright 2008 by EBG Consulting, Inc.
Author: Ellen Gottesdiener, Principal Consultant, , helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time. Her first book, Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Her more recent book, The Software Requirements Memory Jogger is becoming the “go-to” industry guide for requirements good practices for business owners and analysts. Ellen’s company provides high value training, facilitation, and consulting services to agile and traditional teams. You can subscribe to her free monthly eNewsletter and visit the EBG Consulting web site for articles and other resources.