Mindbox has been working with clients since 2006, but only in the last few years has storytelling become central in our day-to-day routine. Of course, storytelling is not new to the software industry. Agile teams have long used user stories to describe software functionality. Here are three reasons why Mindbox decided to take a story-based approach to software.
1. Stories are easy to tell and retell
In our world of video conferencing, we often get approval from a client or production team over a call. For many reasons, it can be extremely challenging to read software requirements to someone for feedback. User stories create a format and a cadence that people can listen to and absorb.
Here’s a typical exchange:
Me: Let me read these stories to see if I’m missing something. As an admin user, I can add a featured photo to a lesson, so that it can be displayed on the frontend. I can see it and edit it in the edit lesson view of the admin panel. As a logged in subscriber, I can see the photo when I am in search or in my library, so that I can recognize it right away by color.
Client: We also need the photo to show up in the user’s favorites view and the archives.
Me: Do they need to be able to delete their lesson photos, or can we do that later?
Client: Later is fine. Let’s do this.
2. Stories are relatable
Before we adopted user stories, we found that our clients simply weren’t reading our lists of software requirements. The number of times I heard, “I thought we talked about it doing xyz” was a clear indicator. We very rarely hear that statement anymore.
Since we adopted stories, our clients not only read the requirements, but actively provide corrections and feedback before development starts, saving them big money and demonstrate that we treat our clients like partners.
3. Stories provide context
When we plan software projects, we know that we will never account for every scenario up front. User stories provide teams with context, so they can make decisions with the right vision in mind.
If I ask a developer to make a button blue, then realize we need another button next to it, the developer will probably make it blue, too. Alternately, I could say, “As a logged in user, I see this button is blue, so that I can easily find the upgrade call-to-action.” This way, if we need another button, the developer is likely to make it in the original color unless it is an upgrade button. This is an oversimplified example. The point is that the motivation for the request is clear.
Understanding the reason behind a request empowers the team to work towards the same goals.
In other words…
We have found storytelling not only empowers our team members, but also our clients. We have seen greater success with our clients, and one of the reasosn is that they have been more involved in the process. As a result, we have been able to make big steps towards building their dream software together.