Stories and Software

I bet you have heard it loads of times. Something like, “Build quality in.” This often floats around conversations on how testing “doesn’t improve quality.” There might be some merit in these statements. 

That merit often does not reflect the point the various pundits and adherents think it does. 

I prefer to think building software better begins at the very beginning. That is a very good place to start. Somehow though, many people, teams and entire organizations overlook that most important idea: Begin at the Beginning. 

What is the beginning though? Where do we find it to begin with, altogether?

Loads of people look at “the beginning” as the “story” or “user story.” Yet when you read their stories, there is nothing of the story about them. Rather than inviting us in and explaining the problems faced in easily understood terms, there are usually cryptic, snubbed, blunt things posing as “stories.” 

Those are not stories and that might be the issue. People have forgotten what a story is. Indeed, when we try to explain our work as a story, we usually fail. 

Let us consider another idea. What is the Story of the Work?

Stories and Context
Loads of organizations use some form of “story” to define work items. Many of these same organizations look at their work items either as components of a larger entity, or items complete in and of themselves. 
​
If they really describe something that can be implemented as a stand-alone work item, that is great. Many organizations have work items that are massive. These are broken into smaller chunks. Depending on how they manage their work items, these big-huge ones might be “features” or “epics” or something else. 

The challenge I see for many is as work items get more granular, their relationship to the feature, the overall story, is weakened or lost altogether. As they get more detailed they must keep the relationship with the main story of the feature. Each of the work items need to keep the relationship between the items and the main feature. 

The feature describes the outline of the story. It provides a framework of the story. It provides the context of the business purpose. It provides the problem encountered and it provides the description of the desired functionality. 

With a complex “story”, the exact details need to be mapped out one at a time. Each of these details tend to be reflected in smaller stories, or stories within the main feature. 

One helpful idea I have found is that the “feature” describes the main story. Each “story” within it describes one piece of it - a chapter. A well structured chapter, just as in a book, can stand on its own, even when being part of a larger whole. 

What makes a Story?
Wise and intelligent people can explain the telling of a story - the Narratology of the story. People can explain it with examples and explanations of how to tell a story well and effectively.

They can tell you how to make the story reach out and draw people in. The literary devices that are part of telling a story. The weaving of the elements into a compelling story. 

What are the elements that make a story?

They are simple to name. Every story has a Hero. This is the central piece the story revolves around. The Hero is opposed. Usually, this opposition figure is cast as a Villain - something evil who will work to defeat the Hero at every possible turn. 

There are problems to overcome. They are external, the obvious issues to address. There are internal problems, issues that the Hero needs to address and find a way to overcome. Then there are the fundamental problems to overcome. In some stories these might be philosophical questions. What sends the hero out? What is the conflict between the Hero and the Villain? What is the root issue that is motivating the Hero?

Granted, not all stories have three types of problems. They can be simple, smaller stories, but the ones that stick and the ones people remember, have all three. 

There is one other piece. 

Most Heroes need a Guide, or Helper, to aid and help the Hero find the path and stay on it. The Guide doesn’t solve and overcome the problems the Hero faces. Instead, the Guide gives the Hero aid, information and support and choices to make that will set the narrative down the path.

Those are the elements found in a story. Granted, most “user stories” used to make software don’t have those elements. When looked at together, all the stories that are related, are these elements present in some form? If not, we likely have a piece of the puzzle - the piece that is contributing to software not working in the way business customers expect. 

Do these things come together into a single element? Do the stories of how we work add up to explaining what the application we are working on will work when we are done?

Heroes in the Story
What are the stories describing? Who are the Heroes in the stories we use? Usually, the Hero is the focus of the story. Is the Hero the software team making the new system? Or is the Hero the person from the business area who uses the software?

With “user stories” where the Hero is the development team, I think something has been lost. The development team is doing work to benefit the Hero. Usually that is the “business” side - the “Users” in the “user story.” 

Why? Why would I say that? Simple. It is their problem we are helping to solve. It might be argued that they NEED us. Somehow though, that seems to be unrealistic. Particularly if the problems they are having are the result of software we are responsible for maintaining.

While we might like to present ourselves as the Hero, it isn’t our story. 
​
It is the story of the problem our Heroes are facing, and how they overcome those problems, with help. WE are the ones providing the help.

Maybe I should back up a moment and give an example, like this: 

1. There are people happily doing their work.
2. Something changes that impacts their ability to do their work.
3. Something needs to be done to allow them to do their work happily again.
4. They can describe what they think they need to do.
5. They need help making that possible.
6. When the changes are made, they need to be able to compare what was done with what they need to be able to do.

That is the Story. That is the User Story. The User is the Hero with a problem. The people providing the help in step 5 are not Heroes. They might be Guides, or helpers to the Guides, or both. 

In Software Stories, the helpers in Step 5 are the Development team. If that is not the case in your stories, that might be worth considering.