Storytelling in IT - Conversation matters
Storytelling in IT - Conversation matters
Join the DZone community and get the full member experience.Join For Free
Monitor your CI/CD pipelines end-to-end with Hygieia, an open source dashboard from Capital One.
Great minds think alike, and fools seldom differ." implies that consensus is often the result of a coincidence or luck. If you look at the success rate of presentations, you might actually think that this is shear luck. So why is it you recall the exact words of a movie or a bedtime story book and not a single word from your last meeting?
Well, as Ben Kenobi tells us: "In my experience, there is no such thing as luck." . There is a method to this madness. Outside IT, people have been practicing the art of storytelling for centuries with good results to convey their message. This post explores the possible links and usage of the noble art in IT.
User Stories: developing the story, creating your scenes
Instead of writing long specifications, Agile developers describe the functionality they develop as User Stories.
They are usually expressed as: "As a role, I want goal/desire so that benefit"
The benefit over traditional Use Cases and other requirements methods, is the conversation: this is used during the requirements discussion with the customer. And because it is in the language the business understands, it works better then dry technical documents. But the highest benefit is that it keeps the conversation going.
- Introduction to User Stories by Scott W. Ambler
- User Stories Applied by Mike Cohn
- Agile Story Telling
- Agile Story Development
Personas: defining your characters and giving them a context
While writing these user stories, finding a good understanding of the roles or actors is crucial. Graphical and User experience designers use the concept of Personas: A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. Personas represent fictitious people which are based on your knowledge of real users.
Story Mapping: make the stories consistent
Now that you have all your smaller stories and your personas, the next step is to make them consistent. A technique used for that is called User Story mapping introduced by Jeff Patton. It expresses the overall story, the global picture that you want to convey.
Another great way is thinking in metaphors: it is something we are used to, it simplifies the model of our thinking and reduces things to the core. They often appeal to our collective memory.
"The user story map provides a useful tool for the entire team to understand the big picture – to see the entire breadth of the system and its diverse set of users and uses."
- Great presentation by Jeff Patton on User Story Mapping
- The new story backlog is a map
- User Story Mapping
- Story Development approaches
- Metaphor Storytelling and Agreement in Software development
Storytelling in Business or IT in general
On the Wikipedia page about Storytelling there is at the bottom a description on using storytelling in a Business context: "For businesses, communicating by using fiction storytelling techniques can be a more compelling and effective route than using only dry facts."
Within IT, we are used to dealing with facts , but not everybody within the IT industry is used to them. We have non-IT savvy managers, users , business owners. Did it ever occur that you were in a meeting where someone was proud that they just gave you the mere facts, but you couldn't remember it afterwards? This is also described in the book Death by Meeting .
There is nothing special about IT, we can apply storytelling to sell a new idea to our boss, our clients, our users, our colleagues. Or make use of it to promote our products/services. This can be either at the individual level or at the corporate level: you a person selling your services, or you as part of the organization selling your services.
Once Upon a Time points out the characteristics of a good story:
- Simple and Specific: to general and your audience will fall a sleep, keep it simple and to the point
- Connection and Resonance : make it ring a bell with your audience, connect with their interests
- Plot and Context: don't give it away all at once, and place things within the right context
Zag Gemignani explains that a good format for your business storytelling might be:
- Climax: Conclusion
- Context: Background to ensure everyone understands the situation
- Dramatic unfolding: a) analysis framework; b) supporting evidence
- Climax: Conclusion, again
- Patterns and Story Telling explains the relationship between storytelling and patterns
- Storytelling in Projects: transforming project plans in stories (pdf)
Caveat: the dangers
Storytelling is a great way for making a message stick, but also involves some dangers. Stories can intentionally or not, give the impressions that certain decisions, assumptions have been made. Or it can make things more vague. More information can be found at:
Storytelling in general:
We all know a good story when we hear it. It's about a clear message, a good plot, good characters. But what makes it good? I'm by no means an expert, but I found the following links good explanations on general storytelling:
- Outstanding Presentations
- Influence through StoryTelling
- StoryTelling 101
- Look Inside Speak Human
- Book: Storytelling in Organizations: Why Storytelling Is Transforming 21st Century Organizations and Management
- Story Telling Techniques
Writing a good story, isn't always easy. You might find some inspiration in books about screenwriting, such as 'Raindance Writers Lab: Write + Sell the Hot Screenplay', which also has a workshop.
Another workshop I've heard good things about is the 'Beyond Structure workshop' by David Freeman. It specially goes into detail to develop your own characters.
Published at DZone with permission of Patrick Debois , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.