The Importance of the Conversation in a User Story
Back in 1998 Alistair Cockburn, the co-author of the Agile Manifesto, 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 important that conversation is.
To recap the video, it’s winter and a mother and toddler get locked out of the house. Luckily, the mother left a window at ground level unlocked. After clearing out an uncooperative cat, she asks her adorable toddler, Holden, to enter through the window, climb on a chair and unlock the door from the inside.
The child enters the house and chaos ensues: he finds a chair next to a table, but proceeds to grab a bowl from the table. His mother asks him to “FOCUS” and he starts moving the chair towards the door. He then finds a pebble on the carpet next to the door and proudly brings it to his mother. The mother gracefully accepts the pebble and asks the child to get back to the mission. He then knocks over a set of fireplace tools and hilariously starts playing with its different items. His mother has to remind him of the problem at hand and coax him to finalize the task.
In the end the boy manages to bring the chair to the door and unlock it from the inside to the absolute delight of his mom and ours too.
This video is very similar to how a user story is written and implemented.
The mother, aka the product owner or business analyst, identifies a problem that needs to be solved: “We gave Dadda our house keys, we are locked out of the house”.
After clearing out any potential prerequisites for the story (removing the cat) she proceeds to state the user story: “I need you to go inside and unlock the door” with the implied 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 the user story? 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, don’t do laps around the house?
Seeing how the action unfolded we would be tempted to say “Absolutely, yes!”. But if this user story were to be implemented by an older child, or a smaller sized adult, the user story as stated would have been enough.
We shouldn’t aim to dumb down the user story to the level of the least experimented team members, as this would clutter the story and make it tedious to follow for the others. Stuffing a story with many acceptance criteria also prevents the team members from thinking of creative ways to deliver the value. State only the ones that would truly make a difference, that provide special context or business rules.
This does mean that, as in the case of this toddler, a lot of follow up conversation may be needed during implementation if a less experienced team member implements the story. Without multiple conversations the user story would not be delivered as intended.
We see that the involvement and presence of the product owner during the team member’s work was crucial in delivering the user story from this video. I particularly appreciated the encouraging way the team member was supported in delivering the task, and prevented from going too far into side quests. In terms of development this could mean delivering value faster by eliminating use cases that are unlikely to happen.
The video also illustrates how the estimated effort of a user story in terms of effort points translates to a different implementation time depending on who implements the user story and why it’s dangerous to try to equate effort points to time. While a user story may seem trivial to implement to some, it may take much longer to others.
Do you agree that fewer acceptance criteria and more conversations are better? Hou would you have written this user story differently?
PS: Thank you Mihaela Marian for sending me the TikTok. :) and happy holidays to everyone!
