Over the years I’ve practiced various flavours of IT development in projects with emphasis on use case driven approaches to guide requirements capture. Not all companies work this way and for many creation of a lengthy functional requirements document is the norm. Without an FRD / PRD / ReqDoc or whatever the in-house term used, the functional requirements are often fragmented and hierarchical with lashings of must haves, should haves and could haves. And in many of my projects the use case has successfully challenged this status quo with an improved way to cluster and manage requirement complexity.
Some projects along the use case migration road have not been so successful and there seems to be a trend to these types. A bad smell may begin with endless reviews in which more detail is added and more critique ensues. Business won’t sign-off and development is stalled and eventually the project misses its window of opportunity and is canned. Or the number of use cases seems to keep increasing with ever more elaborate techniques to package, include and extend them. The Business becomes frightened to read or review and loose faith in use case salvation. Or the estimates raise eyebrows and a new project manager is called in to tame the beast. The PM brings along new metrics in Excel; an impressive plan in Project and development begins, milestones come and go. The first use case never reaches QA for test. The project takes a vacation.
So what’s going wrong and can an agile approach help? Clues left behind by failed or failing IT development projects are useful forensic evidence. Larger companies may have resource to carry out their own post mortem as post implementation reviews. I’ve witnessed two recurring themes from these reviews. First killer is complexity and can be reduced and controlled by user stories. Second killer is lack of iteration borne out of waterfall mindset and this requires enlightened confident management.
Complexity just happens. It’s often not intentional, use case specification just get longer and more detailed. What starts as a simple happy day with a few sentences becomes a heavyweight monster, detailing a multitude of alternatives and exception scenarios. All parties agree these are important. But the project plan has a single task for the whole use case – there so many use cases so we can’t have separate activities for each one can we? The developers wrestle with the monster use case and may get some scenarios working but there’s never enough complete to make it past QA. One way to avoid the monster is to focus only on the happy day and perhaps one or two alternatives. The use case is manageable and can progress through analysis, design dev and test. Success? Not necessarily as those missing alternatives and exceptions are identified during release testing and requires further iterations to fix the defects. But this is ok, the dev team have been through the build cycle and the team can cope so long as release dates are flexible. Success depends on not getting bogged down during requirements definition and producing something that demonstrates delivery is possible. Agility wins the day by accommodating change – the requirements we skipped over at the start get fixed after some code is working.
So was the use case to blame? Maybe. Use cases have become collections of scenarios all working towards a common goal – something of benefit to the business. But just as use cases are collections of related functional requirements, scenarios add another dimension and complexity is multiplied. Think about it; with five requirements related to registering new user, if 4 scenarios are identified that’s twenty requirements that need developing and testing. The use case is overloaded and may hide underlying complexity. An eight person-day estimate to code the use case for one scenario may translate to 32 days when all scenarios are included. If early happy day estimates are used to construct the project plan budgets are soon blown.
A user story helps avoid overloaded by keeping the scenarios separate. The story captures one or two tightly bound scenarios with a crucial constraint – it must be possible to code the story in a short time, say a maximum of 1 week. The agile approach does not allow story bloat. Yes more stories are needed to capture all the scenarios but there’s no insistence that they must all be identified before a line of code is written. Complexity is still there but never all at once. Each iteration builds towards complete functionality covering more scenarios but never all at once. The story becomes the unit of planning instead of a use case that may contain dozens of stories.
Agile methods talk about story velocity and it’s an important concept. The velocity is the number of stories coded per unit of time, typically in person days. For example, our current team has a velocity of 5 stories per day. Perhaps story inertia is an even more useful term. Consider the effort in getting a development team moving. The larger the story, the more inertia and effort needed in getting it moving but once moving it’s easy to add more stories and get working code out the other end. An agile process starts by keeping initial requirements concise and simple in a few stories so development can get moving – low inertia. Then stories for the alternatives and exceptions are added, refactoring where necessary. Another benefit: later stories don’t need as much detail as the initial story has already defined the main pathway and show the way.
Contrast this with a full use case driven development in which as many scenarios are analysed and detailed before any coding begins. Picking any use case to start development brings along all its scenarios in one chunk of code. High inertia, a big flywheel to get moving.
