In 1998, Alistair Cockburn coined the phrase: “A user story is a promise for a conversation”. In this hilarious TikTok of a mother and toddler locked out of the house, we see how essential that conversation is. It shows how a simple task like opening a door from the inside, may need more conversations to achieve.

The video is about a mother and toddler locked out of the house in winter. To enter the house the mother asks her toddler to go through an open window and open the door from the inside. The child enters the house but gets distracted several times. His mother has to coax him to focus on the task. In the end, the boy opens the door to the delight of his mom. This is a lot like the process of writing and implementing a user story.

Writing The User Story

The mother, aka the product owner or business analyst, identifies a problem to solve. “We gave Dadda our house keys, we are locked out of the house”.  After clearing out the prerequisites for the story (removing the cat) she states the user story. “I need you to go inside and unlock the door”. She implies the user value “so that we can both enter the house and not freeze to death”.

Is this a good enough user story? Is it detailed enough? Should she have stated a lot of acceptance criteria in it? Like, don’t take any bowls from the table. Don’t bring me pebbles from the carpet. Don’t play with the fireplace tool set. And, don’t do laps around the house. Seeing how the action unfolded we would be tempted to say “Absolutely, yes!”. But if an older child implemented this user story, the stated one would have been enough.

We shouldn’t aim to dumb down the user story to the level of the least experimented team members. That would clutter the story and make it tedious to follow others. Many acceptance criteria prevent the team members from delivering value creatively. State only the ones that would make a difference. Ones that provide special context or business rules. 

Implementing the user story

You need follow-up conversations if a less experienced team member implements the story. Just like this toddler. Without the conversations, the user story won’t deliver the intended value. But, through tackling this part, you’ll ensure every member of your team has a shared understanding of the situation and can confidently think about solutions.

The involvement of the product owner (mom) was crucial in delivering it. I appreciated the encouraging way she supported the team member to deliver the story. And, how she prevented him from going too far into side quests. In development, this means delivering value faster by eliminating unlikely use cases.

At the same time, the video also illustrates how the estimated effort points of a user story are relative. The time needed to implement depends on the person. That’s why it’s dangerous to try to equate effort points to time. While a user story may seem trivial to some, others may take much longer.

Conclusion

From my perspective, conversations are vital to the successful implementation of a user story. While this video illustrates this concept in a fun, lighthearted way, there are other ways to learn more about this topic. You can further read this article by Matt Wynne. He explains how you can take the conversation to the next level using Example Mapping. 

Do you agree that fewer acceptance criteria and more conversations are better? How would you have written this user story differently?

 

Article written by Sergiu Pocan