January 30, 2014

...Learn TDD with Codemanship

Software Design: Stick To The Story

One thing I try to remind teams of whenever we're thinking about the design process is to stick to the story.

A user story tells the story of how a user gets what they want by using some feature of the software. It's not much of a story, I grant you. Just the 30-second elevator pitch, really. A user story tells us just enough to know if the feature has any value and who to talk to about fleshing the story out.

Extreme Programming teams sit down with the customer who wrote the story and elaborate it into one or more examples, adding meat to the bones of our user story in the form of acceptance tests with example data to make them explicit.

When writing acceptance tests, bear in mind that we are still telling the story of how the user gets what they want from the software. More detail, but same story.

Acceptance tests may then feed into our design process. We may use them as the basis for a user experience design, creating storyboards illustrating how it will actually look as a GUI and what physical form the user's interactions will take (button clicking etc.)

Again, it's important to remember that our storyboards are telling the same story as the acceptance tests and the user story upon which they're based. More implementation detail, but same story.

Acceptance tests may also drive an internal software design that identifies modules or classes, the functions each module or class performs, and how these parts will interact with each other to co-ordinate the work.

We may apply the GUI and UX design, and map our high-level designs onto a physical architecture (e.g., HTML, CSS, JavaScript, JEE, Neo4J etc).

And again, we must remember that our physical implementation design tells the exact same story that the acceptance tests, the UX storyboards and the original user story tell. More detail, same story.

The reason I think this is important is that I often see teams deviating from the story during the design process. A common example is UI wireframes that show details that aren't needed to tell the story. But I also catch teams adding internal "plumbing" that has nothing to do with telling the story.

All these extra bells and whistles that we might dream up while exploring implementation design are not serving the story, and all come at a cost. It's not uncommon to find costs doubling when teams add frills the customer didn't ask to. It's also not unheard of for teams to be so focused on their inventions that the user's original goals end up being overlooked.

I keep a notepad with me so, if I'm working on a feature and have a brainwave about how to make it better, I can talk to the customer about feeding that in as a new requirement.

So, when it comes to design, the trick is to stick to the story.

Posted 3 years, 11 months ago on January 30, 2014