In an Agile team, effective verbal communication can be achieved through the art of storytelling. It performs a crucial organisational role by assisting in the creation of shared meanings for all members of the team and organisation alike. Stories help explain core principles and exemplify how things are done in an organisation. A higher level of organisational commitment and team success is correlated with the story's tone, force, and frequency.
The success of the Product Owner/Product Manager in guiding the team to successful delivery and generating revenue for the organisation is reflected in the calibre of their stories. The culture of an organisation can be reinforced and perpetuated with the use of stories.
Storytelling plays an important role in reasoning processes and convincing others. In meetings, the managers preferred stories to abstract arguments or statistical measures. When situations are complex, narrative allows the managers to involve more context. (Jameson, Daphne A., 2001).
Storytelling in Feature Request and Implementation
As a Product Owner at LITT, storytelling has been a relevant tool in my portfolio, helping me build an understanding of the development process, channel the company goals, prioritise features, and also turn ideas into reality by helping the development and operations teams work together in implementing prioritised features on working software, making business goals a reality. From writing a user story, to helping developers better understand the customer requirement, to implementing a specific feature and making an idea into reality, storytelling, is very essential in the whole software development process
Imagine the following approaches where a product owner conveys information to the development team about a payment feature to be implemented:
Scenario 1: A product owner stands in front of the team and says, "Okay, team, we have been asked to implement a payment feature on our web app. Let us break this down into different user stories that will help us achieve this sprint goal."
After some discussion, the developers decided that the implementation should be divided into several user stories with the task to address the frontend, backend, and when payment is not needed for services that are free on the web app. The developers are not too sure about the work, but at this stage of the process, the team concluded that the various user stories cover the basics of the work and are estimated for it.
Scenario 2: "Okay, team, we have a request to add a payment feature to our web app." The product owner addresses the team after calling everyone together. I am aware that there will be a development effort required to put the feature into place, but we also need to collaborate with internal teams from finance, security, and SysOps since they will be involved in the relevant business process. Why don't we discuss what it takes to collaborate with other teams, choose who may be in charge of such discussions, and make sure we schedule time for both coding and coordination as well?
"We should also take into account the priorities of other teams so that we're looking at the same timeframe from a schedule perspective. In addition, I'd like to explain why we are creating this function and what benefits our company hopes to benefit financially. I can own those discussions since I am the product owner, but if someone asks a design and implementation question, I will go back to the team and ask. Additionally, I'll share information and updates about anything else that needs to be coordinated or known along the road.
From the second scenario, we could tell that a story is told where the product owner tells the team the purpose of this feature, the business value, and who is involved in achieving the common goal, letting them know that although the development process is necessary, other parties also play a huge role in making sure that the implementation of this payment feature is achieved, and as a product owner, he can own the conversation, but technical implementation-based questions are asked, and he will need the teams' assistance to address such questions.
How to become an effective storyteller
Storytelling is a powerful tool that can be used to communicate and collaborate effectively in an agile team. Just as stories have a beginning, middle, and end, thinking of work in a story format helps visualise the beginning, middle, and end of the work.
To become an effective storyteller at LiTT, three important aspects of storytelling are considered.
Firstly, consider different perspectives from various organisational departments that are impacted by your application. Consider which members of these groups should be involved in discussions about requirements for user acceptability testing and exchange information completely and openly in the form of stories. Consider many viewpoints for each need and the operation of the process from ideation to implementation.
Secondly, realise that when you share information only on an as-needed basis, you could prevent someone from acquiring crucial insights into the work. This can prevent crucial collaboration and affect your capacity to provide value to customers.
Thirdly, remember that storytelling doesn't always entail fables. Stories are much more motivating than a list without any context since they can motivate and help to provide a wider perspective of the objectives and goals of a project.
