Success with Requirements

In fact, successful agile development is 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 notice a number of key practices related to requirements.

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 customer defines business value and shares the vision and goal of each iteration - and the overall product - with the team. Often the customer 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 customer). Thus, agile methods rely 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.

Successful 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 backlog changes as business conditions change, technology evolves, or new requirements are defined. The customer 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 customer selects a subset of requirements to build in each 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. 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 recently working with, a known problem with the test platform reoccurred raising the need to create a new infrastructure story to build a stable test platform.

On an agile project, requirements work is often done just in time. The business analyst and customer work during the prior iteration on 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.

Collaborative 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 1980's) as well as DSDM. Lightweight, just-in-time workshops are an effective way to promote and sustain active customer involvement.

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.

~ ellen

Standard citation for this article: