Storytelling as an activity often conjures up images of small children and nap times, but that doesn’t need to be the case. It also can be a powerful tool for communicating information on agile teams.
Storytelling in business is about sharing the context—explaining different aspects of the same information through different perspectives, such as the customer’s point of view or various internal department needs. When we only share the coding parts of a story during sprint reviews, many stakeholders can’t ask relevant questions or participate in the conversation because they don’t see how the software fits within the organization. Unfortunately, sometimes different people don’t believe software developers need these additional points of view, leaving the developers to have a minimal understanding of the real need or purpose for what they are building. The more each person shares their point of view, the more the knowledge deepens, which provides a solid story in a business context.
Imagine the following two scenarios and how the use of storytelling can help both the Scrum team and their stakeholders through the building and production delivery of a new feature.
Story Grooming and Feature Requests
Suppose it’s been proposed to develop new functionality that adds PayPal as a payment option to a website being implemented. The team is ready to groom the story with the product owner and begin the work.
Imagine the following two approaches to conveying this information to the team.
Scenario 1: The product owner stands at a dry erase board and says, “Okay, team, we’ve been asked to add PayPal as a payment option to our web app. Let’s break this one request into multiple Jira tickets we believe we can estimate so we can plan the work.”
After some discussion, the developers decide the implementation can be broken into three separate Jira tickets: one to build the front-end work, one to address all the back-end work, and another ticket to make the payment option a feature that can be toggled on and off so they can roll out the implementation slowly. The developers are not sure about the work, but at this stage of the process, they figure three tickets at least covers all the basics and they’ll be able to start guessing about the work. The session ends in a rush with vague estimates added to the Jira tickets, but no one seems too enthused.
Now, instead of that scenario, envision this alternative.
Scenario 2: The product owner gathers the team together and says, “Okay, team we have a request to add PayPal as a payment option. I know there will be development work to implement the feature, but we also have to work with other teams internally across finance, security, and SysOps, as they will have a role in the associated business process. Why don’t we talk about what it takes to work with other teams, figure out who can be responsible for those conversations, and make sure we plan time not just for coding but for coordinating, too?
“We should also consider other teams’ priorities so that, schedule-wise, we’re looking at the same timeframe. I also want to talk through why we are building this feature and what we hope to gain from the financial side of our business. As the product owner, I can own those conversations, but when people ask technical implementation questions, I will come back to the team and ask. I’ll also provide updates and insights into what other people need to know or coordinate along the way.”
If you were part of this team, which scenario would you prefer?
My preference would be the second one, where a complete story is told. Hearing the reasons something is being implemented helps provide background and context. Also, the recognition that multiple departments within the company need to be included would offer me insight that the software coding work won’t be the only element to think about in order for this feature to become used in production.
And while the product owner might ultimately own the conversations with those other teams, I might be called upon to answer questions and to coordinate with other people in the company to make sure we add business value. How much more interesting does implementing this feature sound now!
Sprint Reviews and Feature Demos
Let’s stay with our example of a team adding PayPal as a payment option to their web app, except now imagine the sprint review through the following two scenarios.
Scenario 1: A developer starts the session by welcoming the group and taking control of a shared screen to show what has been implemented. The developer tells the audience that Jira tickets 1089, 1090, and 1091, which are associated with adding PayPal functionality, have been completed, then shows the addition of PayPal as a payment option.
She asks if there are any questions, and the audience remains quiet. The next developer takes over as presenter, and the process continues.
Now, instead of that scenario, envision this alternative.
Scenario 2: The developer starts a sprint review by telling the audience that the business owners have told the team there has been an increasing demand for a PayPal payment option in the application under development. Additionally, the internal security team has told the development team (as well as the business owners) that a PayPal implementation will pass compliance testing easily, and may in fact alleviate some existing security compliance risk around credit card processing. Further, the finance department has been updated throughout the implementation so they are ready to track PayPal transactions.
The developer then tells the group that the product owner handled most of the exchange between the Scrum team and the finance department but that everyone on both teams realized the production go-live date needed to be coordinated.
A person from the compliance team and someone from the finance team smile and nod as their departments are mentioned. Already the PayPal functionality seems to be an atypical feature that has called for considerable collaboration.
The developer then explains why there were three Jira tickets created to represent the work and says that only when all three tickets were completed would the new payment option be ready for use in production. The developer demonstrates the new PayPal capability but only minimally references the Jira ticket numbers, because the business need means much more to the audience than ticket numbers do.
Once the presentation is done, the developer tells everyone that the team plans to monitor PayPal usage when this feature is deployed to track how many customers convert to this new payment option. The security team mentions that they will be part of the ongoing monitoring to see if fraudulent credit card use declines.
The developer finishes by asking if there are any questions about why and how the feature was implemented or about the planned monitoring. The audience asks a flurry of questions, including what payment option is most common to date and who will be responsible for the monitoring. With specific questions brought forth, a more in-depth conversation entails about payment methods, security, and potentially adding business requirements that must be prioritized.
If you were in the audience, which scenario would you prefer?
As a stakeholder, the recognition in scenario 2 that multiple departments within the company need to be included would offer me assurance that many aspects of the software changes have been thought about and orchestrated across teams. Effectively, scenario 2 tells me the whole story, not just the software implementation details.
The second scenario also tells me that the developer has worked with multiple teams as the coding was being built, so when the new feature goes into production, people across the organization will be ready. In fact, the developer seems less like a techie and more like a partner in the business.
If you break the second scenario down, you can see there is a story—beginning with addressing customer needs, continuing through development, and ending with the implementation of ongoing monitoring.
Becoming a Storyteller in Business
You too can become an effective storyteller in your agile organization. Just remember these three important aspects.
First, consider multiple points of view across the departments in your organization that are impacted by your application. Think through who from these groups should be included in requirements and conversations around user acceptance testing, and share information wholly and freely in story format. Do this by thinking of different points of view for each requirement and how the process works, from the start to production implementation.
Just as stories have a beginning, middle, and end, see if thinking of work in a story format helps you to think through the beginning, middle, and end of the work.
Second, realize that when you share information only on an as-needed basis, you could be blocking someone from gaining critical insight into the work. This could block necessary collaboration and impact your ability to deliver customer value.
Third, recognize that storytelling doesn’t have to mean fables! The book The Story Factor by Annette Simmons is a great resource to learn more about storytelling. Stories can inspire and help to give a broader view of what the needs and purpose of a project are—and they’re far more inspiring than a list with no context.
As Simmons outlines in her book, bring other people into the dilemma and let others be part of the solution. This ultimately brings more buy-in and more motivation than giving people orders. Invite inquiry and you create transparency and collaboration.
Storytelling in business is not the same as telling stories to small children. Try a story format and see if it has you thinking more holistically and completely about your agile project—no faraway kingdoms or dragons needed.
