The Water-Scrum-Fall Guide to Requirements

 Recently I have been involved in a number of conversations in relation to more efficient and visible requirements gathering. The issues relate to Business Analysts and the length of time it takes them to complete requirements and when are finally complete, the high level of detail and complexity that is captured - way beyond the scope of the original request. It’s a very easy trap to fall in but there is a way out. If you are in a Waterfall type project then there are some agile principles that can help.

Shut the Gate

One suggested approach to resolve this issue is to have more weekly reports and gate reviews. Fill in a template, email it off, give a weekly update and so on. To infrequent, too impersonal and too easy to paint a picture that is different from what is actually happening. This won’t work. It actually slows the process down. Which in turn means more Gate Reviews, more formal “template” updates and more smoke when you are trying to find the fire.

Think!

What do I need for day one production, use it to refine your scope. This is rapidly becoming my mantra. If I had to drive between Auckland and Hamilton what would I need? A car, licensed, registered, roadworthy car and petrol. Do I need a car radio? No. Do I need Air Conditioner? No. Do I need a Coffee Holder? No.  Think the same way when capturing requirements.

Manage

The second part of the solution is being managed, both the person and the tasks. No one should be allowed to work without reporting progress and having visibility of what they are doing. This is not an SDLC problem, it is something that Agile will not resolve, this is a person management problem. 

Be Agile-ish

What I have recommended is to add some good Agile practices to the Requirements phase. You don’t need  to wait for the coding to start to use some of the good agile practices.

• Cross functional team, involve the functional, technical and test experts.
There is often a surprising amount of business logic in the heads of the Developers and other technical experts. Their input into the requirements is vital to ensuring they are sensible, manageable and realistic.

• Daily stand-ups
Discuss progress, issues, upcoming events each day, do not wait for weekly reports, gate reviews, etc. Surface and deal with issues on the day.

• Visible tickets
What ever you are working on can go into a card, sticky note, JIRA ticket. Define the task and whom it is assigned to and hence whom is responsible. Completing requirements still means working through a series of tasks and having them visible means progress can be tracked.

• Define done before you start
Decide on what you need for day one production readiness. Think the basics. Keep the requirements you capture as simple as possible and for each one define what is done. This makes life significantly easier for the developer, tester and those doing the user acceptance testing. Also it helps prevent scope creep as it prevents different uninformed and undefined perceptions of what is done.

Build Frequently & Demo Often

Once the requirements are signed off, sprint (literally) to get the first build in front of the customer. At the completion of the first demonstration the customer(s) will provide feedback which will mean changes. Don’t think of these as scope creep or changes, but the natural evolution of the software. 

Rinse & Repeat

Again capture this feedback, discuss, socialise, make it visible, define done and track it. Be pragmatic, if you find a method or approach that works then use it. Mix methods to find the best results. Never stop trying something new to solve a problem.