Agile requirements
Agile Requirements
Agile collaboration teams capture requirements at a high level.
Agile collaboration can be mistaken by some as meaning there’s no process; you just make things up as you go along! That approach is not so much Agile but Fragile!
Although Agile collaboration is much more flexible than more traditional collaboration methodologies, Agile collaboration 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 collaboration teams can build better products/services if they have a reasonably clear idea of the overall requirements before setting out on collaboration, 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.
- Big spec up-front is not the way to go, its not in line with the 20-80% rule.
- Also big up-front specs are never up to date when work is being done.
- There is no lengthy requirements document or specification unless there is an area of complexity that really needs 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 collaboration 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 collaboration 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.
Make sure all items (requirements) 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.