The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.
In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices.
Ensure Customer Involvement
Early and continual involvement of the customer, referred to in some agile methods as “product owner” or “onsite customer” is not new. Dynamic Systems Development Methodology, DSDM (http://www.dsdm.org/), the “grandmother” of agile methods, states as its first principle, “Active user involvement is imperative.” (The updated version of DSDM, Atern, focuses on early, continual and rich stakeholder involvement).
The product owner defines business value and shares the vision and goal of each iteration—and the overall product—with the team. Often the business owner works with a business analyst to define stories, create user acceptance tests, assign priorities to stories, and review completed stories throughout the iteration. (On some agile teams, the business analyst even acts as the proxy business owner). Thus, agile relies on the continued involvement and decision making of the customer.
Manage Changes in Requirements
Agile, as well as traditional projects, have practices for managing changes in requirements. Traditional projects use a change control process (including baselining requirements) and a change control board.
You may have heard that agile projects “invite” changes in requirements. What does that mean? After all, changing requirements are a reality in all projects. But that doesn’t mean an agile project incorporates them into project work willy-nilly.
In fact, agile projects use a rigorous method of managing change through the combined use of a product backlog and iterations.
A product backlog contains a list of functional and nonfunctional requirements, each with attributes (such as priority, risk, and effort). The requirements in the backlog are typically documented in a lightweight manner as stories, use cases, scenarios, or tests—not textual specifications.
The backlog changes as business conditions change, technology evolves, or new requirements are defined. The customer (product owner) prioritizes the requirements and makes the final decision about which ones will be addressed in each iteration.
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 session, 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 fleshing 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.
Workshops
Still another practice—collaborative workshops—is integral to agile teams. These workshops have their roots in classic JAD (Joint Application Design/Development in the 1980s) as well as DSDM. Lightweight, just-in-time workshops are an effective way to promote and sustain active customer involvement.
Agile teams use collaborative workshops to plan iterations and conduct retrospectives. Requirements documentation from workshops or informal modeling sessions should be minimal, with a focus on what developers and testers need to deliver the working software.
Agile Requirements Adaptation, Not Abandonment
Agile methods do not eliminate the need for requirements. Nor do agile methods assume you will use good practices in developing requirements. I recommend you adopt a requirements-driven approach to product delivery, whether you’re using agile or traditional methods.
On agile projects, I suggest you define a product roadmap, release plans for each release, iteration plans for each iteration, and highly focused requirements workshops inside each iteration. In a later Modern Analyst eJournal, I’ll discuss this in more detail.
Copyright 2008 by EBG Consulting, Inc.
Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, 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 "Success with Requirements” and visit the EBG Consulting web site for articles and other resources.