Agile Requirements

Agile development teams capture requirements at a high level.

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.

We believe Agile Development teams can build better products if they have a reasonably clear idea of the overall requirements before setting out on development, so that incorrect design decisions don’t lead the team down dead ends and also so a sensible investment case can be made to get the project funded.

However any requirements captured at the outset should be captured at a high level. 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.

An Agile Development team (including a key user or product owner from the business) visualises requirements in whiteboarding sessions and creates requirements and 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.

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.

Stories 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.

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.

One thing I think should certainly be adopted from PRINCE2, the very non-agile project management methodology, is the idea of making sure all items are deliverables rather than activities or tasks. You can see a deliverable and “kick the tyres”, in order to judge its quality and completeness. A task you cannot.

original content from here