User story - Visualization

Challenge

Most of us must have seen the tree swing story. In IT, the biggest problem we face are requirements and  how it gets translated. I have also had the same issue with requirements lost in translation as it goes  through multiple people before it reaches the actual developer and tester. When explaining something  verbally, it is hard to make sure that the person listening has understood what you have in your mind. The  person explaining something has some more context and takes it for granted that the other person is also  on the same level field as the person explaining. In most cases, it goes through multiple people before it  reaches a person who is actually creating a user story and writing down the actual work. There is no  validation until the respective stakeholders look at the finished product to see if what the requested and  what is delivered are the same. Time is already lost due to work that took place to deliver as per the  developer and QA understanding. This video is an example of things are lost in translation when it passes  through multiple people. This is not new and we have probably played this game while we where kids and  tried to explain something sitting around and we see how twisted something becomes when it reaches  the last person.

Selection

The tool I used was visualization. This helped us make sure that we are not losing the idea and the thought  process behind a task that needs to be done. The tool helped people with varied skillset from business to  technical to understand what is being told and what is the deliverable.

Application

In Agile methodology of software development, we have the concept of a personas which describes the  different users of the system and what the characteristic of each user is. In the airline industry where I  work, we have personas ranging from Peter the Pilot, Felicia the Flight Attendant, Glenn the Gate Agent,  Mike the Manager, etc. Each of these personas can also be sub divided based on different characteristics  of the user. Certain customers insists on having the highest service for the money they have, some of  them are happy with what is given and so on. Each of these persona has a page explaining what they do,  how they will use the system and what are their characteristics when they are using the system.

I had the team use a tool https://www.storyboardthat.com/ which would draw a cartoon explaining to  the stake holders on what the user would be doing and explaining every sequence of the user action. In  the team, the product owner is  responsible for creating this cartoon as (s)he is the one directly  interacting with the user. Depending on who the end user is, the cartoon would be depicting scenarios  like a customer trying to check-in bags. This could again be broken down into a customer on a domestic  vs international trip, or could be based on a customer using credit card or miles to make a purchase. Or

this could depict a customer in multi-city transit and is checking mid-point. The other users of the system  could be the gate agent, flight attendant, etc. The cartoon always has a persona on whom the story is  based on. Multiple personas will enter and leave the story. The cartoon clearly shows the interactions and  the sequence of steps to the little detail.

With a cartoon in place, the visualization ensures that everyone has the same understanding of the  requirement and nothing is lost in translation. Once the cartoon was created, I had the product owner  setup sessions with the users, business, technical teams so they have a clean understanding of the work  and they sign off on the requirements.

Insight and Approach

Using this tool helped us in identifying insights and it created more communication and understanding of  the problem in hand. As the cartoons where getting generated, the product owner would clarify a lot of  questions as they are getting into the head of the user. A lot more up front work is done which solves the  back and forth work that usually takes place with requirement. The additional amount of time creating  the cartoon was negligible in comparison to the time that was saved from having the same understanding  across people creating the system and people testing it. The tool allowed for discussions and helped in  creating acceptance criteria which would drive actual development work. The tool did not require any  knowledge of design or drawing. The product owner just had to click buttons and create a visualization  which could then be shared as a cartoon strip to the end-users. To me the biggest win with the tool is the  collaboration and communication that was achieved as well as the speed to market in delivery.

In terms of alternative, we were able to use stick diagrams while trying to white board solutions or use  power point to just draw cartoons and explain the scenarios. Visualization become the default way of  creating requirements within the team.

