How Software Developers Can Use Storytelling to Define Slices of Functionality
Stories distill a particular concept down to its essence.
Humans are storytellers by their nature. For at least 6000 years of recorded history, and a much longer time of unrecorded history, we have passed down stories.
How can you take the best from this lineage of story-telling, and use it for good as you develop software?
We use stories to remember things like historical events. Stories help us teach lessons from the past. Stories help us look towards a brighter future. Stories help us unite and bring us together.
At the highest level, before starting a product or project, there are a couple of stories that you can tell. The first lays out your users current situation, and the problems that they face. The second tells of a better world, after you’ve introduced a solution.
To break down your users problem, you need to understand a bunch of smaller stories. Tell us about their daily activities and interactions. Describe their challenges along the way. These would roughly translate to use cases.
You can break these down further, into specific tasks that need to be done. You can also describe the outcome of the stories.
Don’t use the Connextra story format “As a …, I want to …, so that …”
This format is good in its intention. It keeps you focused on the user and the value they are looking for. In practice, the format can break down.
A more natural style of story-telling is in order, one that goes back to centuries of oral tradition. Present your hero. Lay out the current challenges. Show us how to overcome them and save the kingdom along the way.
Let’s look at this in practice, and take an example from an imaginary gift card marketplace. Any coincidences to a real company are purely coincidental.
Starting at the highest level, we want to lay out the problem, and some possible solutions.
There are billions of dollars lying around in un-used giftcards. People often get the wrong gift card, to a brand or store that they don’t use. The card goes right into their drawer and starts collecting dust. Imagine if there was a way for them to get the value of their gift!
We’ve identified our users, the owners of the gift cards. We’ve also identified their problem, that the value is locked away in a drawer. We hint at the solution.
Let’s stick to this high level, and start to describe a solution we are after.
Imagine a place where people that own a gift card could sell it. People interested in the brand could come and buy it. This place, the marketplace, would make sure that everything went smoothly on both sides.
We’re starting to see a solution emerge, the marketplace. We also identify a couple of other potential users: the buyer, and someone administering the marketplace.
You see how we’ve kept things at a very abstract level so far. We didn’t get into many details, there’s still time for that. The point here was to identify the broad list of actors/personas and the highest level of problem that they are solving.
We’re purposely focusing on the problems first. This helps us to understand the situation better. It also keeps us from jumping to solutions, and creating the first thing that comes to mind.
As we elaborate on the problem, the stories start to get a little smaller.
- A buyer shops like most e-commerce sites.
- An administrator approves the order and pays the seller.
- The seller posts their card for sale.
We may want to put this into a more chronological order.
- A seller submits their card for sale.
- A buyer shops in an e-commerce experience.
- An admin approves the order.
- The seller receives money for their card.
Now we can take each piece and elaborate some more. As we elaborate, we will have more questions than answers. We should track those as well. Let’s see how that might look.
A seller submits their card for sale.
- What information do we need?
- Brand? Selling-price? Value?
A buyer shops in an e-commerce experience.
- Buyer sees a list of cards for sale.
- Buyer chooses a card to purchase.
- Is this a shopping cart? Single purchase?
- Buyer checks out, pays for the card.
- What payments can we accept?
An admin approves the order. The seller is paid for their card.
- How do we pay the seller?
- What information do we need to pay?
- When do we collect this information?
Buyer receives their card.
You see that we’ve done a little bit of elaboration. We also raised a lot of additional questions that need clarification. We also identified one more major piece to the main story: receiving the gift card.
This is an iterative process.
We start at the high level and identify the main story arc. We fill in each part of the story with a few more details. Some questions come up, which we answer or defer. We look at the main story arc again. We elaborate on more details. And on and on.
This could continue for quite a while. We could elaborate this until we know how every detail works, and have every questioned answered. This would feel good, but does not necessarily get us to working software.
At some point, sooner than later, we need to look at turning those stories into something that we can use, explore, play with, and learn from. To do this quickly, we’d like to assemble a series of thin strands together, to tell a simple version of the overall story. To do that, each step of the larger story arc needs to be thin as well.
There is a lot to learn and explore about this potential marketplace. Let’s look at one way to start. We will imagine that we have an idea for a new startup. Our goal is to produce a working prototype, that we can show to potential investors. We want to develop something with a small team, get some funding, and then complete more of the stories so that we can launch our marketplace.
With these goals in mind, where do we begin? Here is one way. There may be others, and that’s OK. The point is to get started. If we use some of the technical practices we’ve discussed, like TDD, ATDD, Refactoring and a simple design, will be able to evolve our software with confidence as we learn along the way.
At the most basic level, we decide to proceed like this.
- Seller submits a gift card for sale. We will not deal with login at this point, so we will trust that they will put in their correct email. For the gift card, we need to know the store, the price and the value.
- Buying a gift card can be broken into several steps.
- Buyer sees a listing of cards for sale. We will show the brand, the price and the value of the gift card. There is no sorting or filtering this list right now, that can come later.
- Buyer chooses a gift card to purchase. At first, we will assume one card is purchased at a time. That simplifies the interactions with the user. If we decide to change our mind, we are confident that we can refactor along the way.
- Buyer pays for the gift card. We know that PayPal allows us to process funds with only an email address, so we will ask the buyer for their email as the simplest way to proceed.
This feels oversimplified. We would definitely not go to market with a product like this. But our goal here was a prototype. We want to show off the application to potential investors as the next step in our growth.
Stories distill a concept down to its essence.
A feature list like this could likely be done by 1 or 2 developers within a couple of weeks. Possibly even sooner.
Imagine how much we could learn about this process by having the working software available to us.
We could elaborate the stories in more detail. We would learn about aspects of the process, of the story, that we could not imagine while simply brainstorming.
There is tremendous value is getting a few thin slices out quickly.
👏🏻 Give me a clap and “follow” if you enjoyed this article.
📋 About Milo
I am a tech executive, writer, speaker, entrepreneur, and inventor. I’ve been developing software since 1995 and developing teams for the past decade. 🚀
I write articles about software, engineering, management, and leadership.
You can also follow me on Twitter. 🐦
