Inside TOPdesk we work with groups from the most varied backgrounds, we have work groups that count with both interns and post-graduates certified in the best market practices, and if there's one thing I've learned working here is the power that a story has when it comes to explaining the purpose of our activities. Simon Sinek has already demonstrated this with the golden cycle, which you can check out in this fantastic video here.
Working with agile teams we usually stress the importance of creating user stories and making them simple for the teams to develop their activities. But talking about using user stories can seem like telling you to size a spoiler for an airplane. Activities that without a foundation can leave us a bit lost when it comes to developing them, so where does this story of using user stories come from?
Studies show that the human mind understands stories better, and the reason for this is kind of logical: we have developed as a species through the sharing of stories. Our ancestors didn't have governance, engineering, or even programming logic to do the hunting, they only had the opportunity to communicate, and to motivate others to the point that they both took on the same goal.
In other words, we have developed and evolved as a species spending a good part of our existence in conversations around a campfire, telling stories about love and goodbye, victories and defeats, achievements and losses. Through these stories our ancestors ruled empires, motivated people, and created the basis for today's logical thinking.
Which is relatively intuitive, just think that if we have experience in different fields, and you ask me for an activity with the language of your expertise, it is common that I find it strange and don't know what it means. It is one thing to ask a civil engineer to calculate the height of the reinforcement cover, but it is another thing to ask a counter-rule to do the same. While the former will calculate a structure, the latter will probably bring you a medieval figure, because both are in different contexts.
The problem is that the difference between the backgrounds of each one is not always so clear and this is what causes the problem, sometimes we believe that our co-workers have the same experience as us, and we forget that although we are working on the same goal, the paths that got us there are totally different. This is why agile teams, which are multidisciplinary in nature, need stories so much to work with.
And this is where they can help us. I like to work on them from the perspective of the 3A's: Actor, Action, Achievable. There are numerous techniques to describe a user story, you can use the acronym: INVEST or actually tell a storytelling, however when you are working agile across the organization it is important to keep the language simple. This is why the 3A's work so well.
The actor is always the one responsible for executing/experiencing the problem/dilemma your team will face. The action is always the one executed by the actor during his moment of conflict/dilemma, while the achievable is the purpose to be reached by the deliverable your team will develop. If we follow Simon Sinek's tip we can start with the why, first delimiting the purpose of that story, and then move on to the actor or action. So a great example of a user story might be:
"To save paper and make more efficient use of our natural resources, I as a reading lover would like to not have to spend paper to read different books."
We have a grand, motivating purpose and a story that is ultimately simple and negotiable. We can create from this the Adobe Reader, the Kindle, or simply a book club that destroys and recycles books with each reading. Creativity rules, the team will come up with the best solution, but the most important thing is that everyone now understands the purpose of their work.
Comments