As a software company, many people are probably affected by the (lack of) quality in the products you provide. If you screw up really bad, the experience can be so frustrating that people almost break down and cry. Instead of helping them get the job done, their computers are actively working against them. Crying is a powerful expression of emotion, one that few share in the workplace. Wouldn’t you feel terrible if you were told that your products triggered negative emotions like despair, frustration and anger in your users?
I’m sure people rarely tell you that. But isn’t that the story we would like told? A story about a human being trapped somewhere out there in that big universe of ours, banging her head against your software for eternity. A story about a dream she is having. A dream of a hopefully not too distant future, where something you do takes at least one of her problems away, and how that makes her happy, if only for a little while. If that’s not beautiful, I don’t know what is!
If you’ve written user stories that for some unexplainable reason didn’t turn out beautiful, don’t feel bad. I have actually made a list that you may find helpful. Since this (as soon will be apparent) is a post about non-violent communication, I won’t call it a list of wrong things (at least not to your face), so let’s call it
A short list of things that may be less than optimal
- You actually write “as a user“. What can be more anonymous and uninspiring than helping out a “user” ? Try describing a real person (persona), her name and her role!
- You’re writing the story, but not telling it. The origin of user stories is attributed to Kent Beck (the guy who came up with extreme programming), “Tell me the stories of what the system will do” – they were originally placeholders for conversation, not written documents. A lot of context and information is lost when you just write it down and email it to someone rather than actually explaining it in person.
- You don’t share how you feel.
Let me explain that last point in a little more detail. Actually, let me introduce what I think is a new (see footnote) variation of the user story.
Introducing the Nonviolent User Story
Nonviolent communication focuses on three aspects of communication: self-empathy, empathy, and honest self-expression. If that sounded a bit touchy-feely, that’s because it is. It’s about being completely open and honest about how something makes us feel, and what we would need from others to feel differently. Yes, even at work. It’s scary, I know.
There are four basic steps to Nonviolent communication:
- State an objective, factual observation that triggers a feeling within you, as well as the need to speak up. Do not include an evaluation, just observe.
- State the feeling that the observation triggers in you.
- State the need that is the cause of that feeling.
- Make a concrete, refusable request that, if fulfilled, will meet the need mentioned in #3.
So, with that in mind, let’s continue.
The traditional story template looks like this:
As a <role>, I want <goal / desire> so that <benefit>
My first draft of the nonviolent user story, looks like this:
As <person in a role>, I experience <emotion> when <observation>. I <need>, would you be willing to <refusable request>?
That probably sounded a bit complicated, and maybe it is. It’s a work in progress, and I welcome any feedback. To make it worse, remember that this isn’t only about writing the stories, it’s about telling them. Maybe even mostly about telling them. I’m not fooling myself, most will probably not write stories in this form, but let’s start by at least thinking about it, and perhaps incorporating parts of it in how we tell the stories. Let’s go through the details, and then try it.
- As <person in a role> – this one should be familiar. Ideally I’m replacing this with Lisa the project manager, and not user.
- I experience <emotion> – Feelings. That’s a bit more difficult. “I feel like the system isn’t working properly” is not a feeling. “I feel like my boss doesn’t like me” is not a feeling. Sad is a feeling. Frustrated is a feeling. Angry is a feeling. I’m trying to express pure emotion, and I trust you not to judge me for feeling this way.
- when <observation> – Pure, objective facts. Not my evaluation of said observation. This is something that happens that I can see, hear or feel.
- I <need> – The emotion typically expressed in a user story like this is negative. Something I observed triggered a negative emotion, and this is what I need to stop that from happening.
- Would you be willing to <refusable request>? – I’m asking if you are willing to do something for me. In return I’m willing to spend time explaining why it will help me and how my world changes if you do it. If you have a different proposal, I will be open to discussing it. The request is refusable, you are not obligated to say yes.
To help articulate your feelings in #2:
Feelings we may experience when our needs are not met
To help articulate your needs in #4:
A list of needs
As Lisa the project manager, I become frustrated when I try to unpublish all products in a product group and realize that I have to manually unpublish each individual product. I need to spend less time managing products. Would you be willing to provide me with a faster way to accomplish this task?
As John the secretary, I become hesitant when I attempt to book a flight for someone else in my organisation, and are unable to figure out how to separately fill in my contact details and the details of the person who is actually going to be on the flight. I need to feel confident that the invoice is sent to me, while the person I am booking for will be able to board the plane. Would you be willing to provide me with a booking interface that clearly separates invoice details and traveller details?
As Maria the surfer enthusiast, I become angry when I am required to provide full personal details before being allowed to join the Big Wave Surfing Community. I need to be able to share my surfing experiences with friends and like-minded enthusiasts without violating my sense of privacy. Would you be willing to change the registration process so that it does not require me to share private information that is irrelevant to the service you provide?
So what do you think? Would you be willing to try it?
also published at www.revio.no
* Footnote: This post has been a draft for quite a while, and when I reached out to Bob Marshall to ask him for input on the idea, I realized he had written a post about a very similar concept called Antimatter stories at about the same time (his post was published February 26th). Bob’s many previous posts about NVC is of course also what triggered this idea to begin with. He also had some helpful feedback on the draft that helped me finalize this post. Thank you! Any errors within this post are of course my own.
On an intellectual level, everyone understands that communication is important.
And everyone in a company is working together with someone else, unless it is a one man company. So without communication, nothing much would get done. Stating the obvious, right?
A recent NTNU (Norwegian University of Science and Technology) Master Thesis concluded that (paraphrased):
“Allthough all organizations think that good communication is vital in order to run projects in the direction of their organizational strategy, most do not have the desired communication systems, culture or skills(..)”
Surely that doesn’t apply to your company. You guys spend lots of time making sure everyone understands what to communicate when, and to who. You naturally share all relevant information to as many people as possible, in a way that makes sure the original message is preserved.
I’m sure that you always make sure that “what is relevant” isn’t defined to tightly, and terms as “on a need to know basis” are generally frowned upon. Informal communication is always encouraged in order to build an environment where anyone will continously voice their intent, their understanding, their worries and their questions without fear of repercussions. Right?
And your managers always make sure everyone involved knows where the team is going and why. When someone does something that is not aligned with the overall goal of the company, they do not blame the individual. They ask “What piece of information did this person not have, and why?” or “What has this person not understood, and how can we help this person understand it better in the future?”
Did I just describe how the concept of information flow works in your company?