requirments

A picture tells a thousand words. So prioritize pictures not words

Draw pictures to illustrate outcomes, design the user interface first and use that to prioritize requirements rather than working with written requirements.

In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence.  This is especially so in developing software which more often than not is visually manifest as a user interface.

When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement.  And we do it in words.  Those slippery things that are so often misunderstood.  Things get really slippery when we try to prioritize those words against each other.  Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority.  And because they are supposedly independent, you loose the inter-depedencies between them.  Jeff Patton has written some great stuff on this.

So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.

Throw out the stories.  It’s too early to be writing words.  Muda.  Create illustrations of widgets and features and functions.  Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire.  On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on.  Identify the stakeholders who will interact with the requirements.  For example the retail website, the operational support application, the finance system.  Now ask the team to stick onto the screens the sketches.

The challenge is to strip back to the minimal functionality that they really need for that first release.    Let them draw extra functionality if they like, but everything must be on post-it notes.  Now pull the post-it notes off, one by one.  What if we removed this? What would happen if it wasn’t there?  Is there something simpler we could do?  Something more elegant?  Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.

That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more.  Any less functionality would not be a meaningful release.  Now we can get down to writing the stories, focusing our effort on something we are agreed looks right.  We’ve prioritized pictures, outcomes over words; Picture Driven Design.

Sounds like a case for agile

..CIOs will be expected to become more and more strategic, delivering greater productivity gains while at the same time ruthlessly cutting costs. There will be a heightened debate about the role of IT in the enterprise. (ComputerWorld)

OK, so we can either spend months writing documents before a line of code is written. Do some application development then manually test what we’ve built and fix the bugs before eventually going live (late and over budget and not to the customers satisfaction).

Alternatively we could get more strategic and focus upon what value we can deliver in the shortest period of time. We could better align IT with the enterprise by delivering early and often, enabling us to test and learn from the enterprise as we go. We could adopt a more ‘just in time’ approach to requirements (whilst starting with a clearly defined vision from the outset). We could build testing into the development to lessen the bugs at the end, we could do automated testing (to ruthlessly cut manual testing costs). Downturn sounds like a case for agile.

.