What if?

Tom Breur

17 August 2014

The number #1 recurring conclusion in project post mortems, after about a half century of developing software, is still “we could have done a better job of gathering requirements”… My esteemed colleague Holly Bielawa has written about requirements craftsmanship, in an attempt to clarify that even (or also) Agile teams suffer from this problem.

Of course the direct involvement of a Customer (or Product Owner) mitigates some of this risk. And frequent feedback is supposed to keep all development “on track”, i.e. representing the highest possible value to the client. Holly makes a strong case, urging Agile teams to take responsibility. To ensure that we continue to build “valuable software”, just like the first principle of the Agile manifesto dictates.

Where do we go wrong? Usually, some imperfect mutual understanding. In Behavior Driven Development (BDD), and Specification by Example (as advocated by Gojko Adzic), we drive towards valuable output by making explicit what success should look like. Engage in dialogue to ensure clarity on what it is you should and should not deliver. How would you know it, if you saw it? By surrounding and clarifying all edge cases, the boundaries of the solution become clearer.

By asking “what if” repeatedly, we try to get examples for success, the litmus tests for value. And make those as concrete as we can. How does your business partner capture value? What do alternative (less successful) scenarios look like? It’s a way to get close, to get a peek inside your customers’ skull, so to speak. Making examples specific is –in my experience– the most powerful way to ensure proper understanding, the royal road to quality requirements.