Agile Principle #4: Agile requirements are barely sufficient!
Agile Development teams capture requirements at a high level and on a
piecemeal basis, just-in-time for each feature to be developed.
Agile requirements are ideally visual and should be barely
sufficient, i.e. the absolute minimum required to enable development and testing
to proceed with reasonable efficiency. The rationale for this is to minimise the
time spent on anything that doesn�t actually form part of the end product.
Agile Development can be mistaken by some as meaning there�s no process; you
just make things up as you go along � in other words, JFDI! That approach is not
so much Agile but Fragile!
Although Agile Development is much more flexible than more traditional
development methodologies, Agile Development does nevertheless have quite a bit
of rigour and is based on the fairly structured approach of lean manufacturing
as pioneered by Toyota.
However any requirements captured at the outset should
be captured at a high level and in a visual format, perhaps for example as a
storyboard of the user interface. At this stage, requirements should be
understood enough to determine the outline scope of the product and produce high
level budgetary estimates and no more.
Ideally, Agile Development teams capture these high level requirements in
workshops, working together in a highly collaborative way so that all team
members understand the requirements as well as each other. It is not necessarily
the remit of one person, like the Business Analyst in more traditional projects,
to gather the requirements independently and write them all down; it�s a joint
activity of the team that allows everyone to contribute, challenge and
understand what�s needed. And just as importantly, why.
XP (eXtreme Programming) breaks requirements down into small bite-size pieces
called User Stories. These are fundamentally similar to Use Cases but are
lightweight and more simplistic in their nature.
An Agile Development team (including a key user or product owner from the
business) visualises requirements in whiteboarding sessions and creates
storyboards (sequences of screen shots, visuals, sketches or wireframes) to show
roughly how the solution will look and how the user�s interaction will flow in
the solution. There is no lengthy requirements document or specification unless
there is an area of complexity that really warrants it. Otherwise the
storyboards are just annotated and only where necessary.
A common approach amongst Agile Development teams is to represent each
requirement, use case or user story, on a card and use a T-card system to allow
stories to be moved around easily as the user/business representative on the
project adjusts priorities.
Requirements are broken down into very small pieces in order to achieve this;
and actually the fact it�s going on a card forces it to be broken down small.
The advantage this has over lengthy documentation is that it's extremely visual
and tangible; you can stand around the T-card system and whiteboard discussing
progress, issues and priorities.
The timeframe of an Agile Development is fixed, whereas the features are
variable. Should it be necessary to change priority or add new requirements into
the project, the user/business representative physically has to remove a
comparable amount of work from scope before they can place the new card into the
project.
This is a big contrast to a common situation where the business owner sends
numerous new and changed requirements by email and/or verbally, somehow
expecting the new and existing features to still be delivered in the original
timeframes. Traditional project teams that don't control changes can end up with
the dreaded scope creep, one of the most common reasons for software development
projects to fail.
Agile teams, by contrast, accept change; in fact they expect it. But they manage
change by fixing the timescales and trading-off features.
Cards can of course be backed up by documentation as appropriate, but always the
principle of agile development is to document the bare minimum amount of
information that will allow a feature to be developed, and always broken down
into very small units.
Using the Scrum agile management practice, requirements (or features or stories,
whatever language you prefer to use) are broken down into tasks of no more than
16 hours (i.e. 2 working days) and preferably no more than 8 hours, so progress
can be measured objectively on a daily basis.
