Günther Gerlach

written by gunther gerlach-2009

Use Cases: are in fact such a clear description of a feature, and the fact that each Use Cases could stand alone. They made it really easy to move cards representing the Use Cases around the

As a difference between this methodology from the others is that Agile Development teams capture requirements at a high level only, just-in-time for each feature to be developed. Agile scrum methodology 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.

Although Agile scrum Development is much more flexible than more traditional development methodologies, Agile scrum Development does nevertheless have quite a bit of rigour and is based on the fairly structured approach of lean manufacturing as pioneered by Toyota.

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

Gunther Gerlach