Telling Stories

by Derek Winter


Transient

I sometimes feel like I work in two worlds that sometimes collide and sometimes inform each other in useful ways that enhance my understanding and capabilities. One such area of overlap and ‘mutual benefit’ is (Business) Story-telling and User Stories.

My career started out firmly in the technical world, I trained as a software engineer and worked for software vendors. However as my career progressed and I spent more time on the client side of technology my perspective on business broadened and in the last ten years I’ve spent more time in a broad range of general business roles not necessarily related to technology.

One of the aspects of developing/designing great software that I grappled with was how to capture the requirements of a client. To really get to the bottom of what users needed and wanted from the systems. The best framework I’ve come across is the User Story concept made popular by an agile approach to software development and written about extensively by many, but particularly Mike Cohn. Follow the link for some depth, but in essence, any requirement for how a piece of software or website should function can be distilled into a statement in the form of “As a [User] I want to [Do something] because [some reason or value]”. (Simple!) This has great power for numerous reasons, but not least of which is that people identify more closely with the requirements when they are written in the first person and the focus on reason or value promotes an understanding about purpose.

I’ve also in recent years enjoyed the work of Shawn Callahan at Anecdote and the concept of Story telling for business purposes. Given the chance, Shawn will passionately advocate that a lot of what is tagged as storytelling these days in the corporate world misses the point and in fact a lot of what is put up as examples of storytelling aren’t stories at all. Again, visit the site for some depth, but in essence a story has to exhibit 4 things to be a story.

  1. Time marker, place marker or character: stories start in one of these three ways but orally they mostly start with time markers. So if you hear someone say, "On Tuesday ..." or "A while back ..." or "In 1991 ..." there is a good chance you will hear a story. 
  2. Events: stories are about something happening; this event followed this event, which followed that event. Good stories help you see and feel what's happening.
  3. People: if you hear people's names, and in particular if you hear dialogue, then you know you are in a story.
  4. Unanticipated: A story is a promise to the listener that they will learn something new. It has to have something that is at least a little unexpected.

And, for a business story it must have a business point.

So, with this in mind, I wondered whether User Stories could in fact survive in the world of storytelling.

Starting with “As a [User]” qualifies for the first test and the third test; We have a character, so we know who the story is about.

The middle section “I want to [Do something]” qualifies as Events … it’s about something that needs to happen, or the way a system should behave when a user acts a certain way.

The promise to learn something new should be encapsulated in the purpose of writing a user story in the first place; The intention is to provide a way to communicate new features or capabilities that are required to be developed.

And lastly, a business point or purpose is covered off by “because [some reason or value]” This part of a user story is sometimes seen as optional, but in fact is one of the key features that identifies what could otherwise be a ‘nice to have’ or cosmetic addition as something of value. This helps the developers understand why they’re building what they’re building (and therefore their solution will be better focussed) and it also helps the business focus on delivering value to the client/customer/user rather than just building what sounds nice or seems popular.

So, it seems to pass the test as a legitimate (if somewhat formal, structured) version of story telling. Why is this interesting or important?

Well, it’s an illustration of how what can seemingly be divergent, unrelated disciplines can in fact inform and improve each other. For example, there is a wealth of writing about how to elicit good stories that would greatly benefit business analysts and software developers in understanding how to enhance their ability to gather user requirements. Poorly defined and communicated requirements are often the cause of poorly conceived software applications.  That could be achieved anyway by improving the gathering process but writing requirements in more traditional, formal ways though. The other value of embedding story techniques in requirements gathering is that stories provide meaning, memory, and caring. "Stories engage the listener, pulling them into the story to participate in the conversation, rather than telling them what to think" (Anecdote) In product development terms, it’s that conversation that will sharpen the implementation of the requirements and focus the energy and effort of those developing it.