Requirements in Agile Projects

Key ideas#

What is different about this kind of project#

Wiegers and Beatty contrast two approaches. A predictive (waterfall) approach reduces risk by planning heavily before development and works when requirements are clear and stable. An adaptive (agile) approach assumes change is inevitable and plans in short cycles. They point out that Royce’s original 1970 paper on the waterfall already called a strict single pass risky and recommended iteration. Their core claim: there are no “agile requirements”, only shifts in emphasis: - Customer involvement runs through the whole project, not just the start. - Documentation is the minimum that gives developers and testers precise guidance; anything more is waste. - Timing: high-level stories fill the backlog early; detail is added just before a story enters an iteration, through a small cycle of elicitation, analysis, specification and validation. - Change is expected, not resisted.

One backlog#

Citing Mike Cohn, the authors recommend a single backlog per project that holds stories and defects alike; with separate lists you cannot compare priorities. Backlog priorities are never fixed.

Quality attributes come early#

Performance, availability and other quality attributes shape the architecture. You cannot wait for “their” iteration as you would with ordinary functionality; elicit them up front.

Stories need an editor#

Stories written by people without analysis experience, including customers themselves, are often imprecise. Someone with business analysis skills should refine them before they are built.

Epics, features and stories#

• User story: sized to fit in one iteration.
• Epic (a term the authors attribute to Mike Cohn): a story too big for one iteration; split it into smaller stories, if needed through smaller epics.
• Feature: a set of capabilities that has value to users; it can span one story, several stories or several epics.

The minimum marketable feature (MMF, from Denne and Cleland-Huang) is the smallest set of stories that the team can deliver at once and that still gives the customer real value. Do not obsess over the labels; the quality of the requirements matters more.

Expect change, but look ahead#

The business analyst’s (BA’s) reflex shifts from “that’s out of scope” to “let’s talk about it”. Expecting change does not mean ignoring the future: a look ahead lets the team choose a more extensible architecture without designing for every hypothetical case. Removing backlog items is normal too, because of implementation problems, findings by the product owner or testers, or more valuable work.

Avoid purism#

The authors describe an organization where rolling out agile “by the book” everywhere at once failed. One team settled on a hybrid (a backlog, three-week iterations, detailed requirements for each iteration) and most agile practices took hold only after people stopped forcing them. Their advice: choose practices that fit your context, start with a pilot project, and bring in an experienced coach for the first few iterations.