How to improve your user stories and become a team along the way
Wherever I roam along the planning boards of agile teams, I discover post-its with cryptic messages on then: “Integrate ST list in Waydev flow” and “Pre-fill customer list with VeDocumentsAPI” and “Design appointment gCalendar”.
Mesmerized by these hieroglyphs I ask the authors of these mystic strings what they mean. The answers I get are usually one of these:
- “You should ask that person. It is her story.”
- “Our Product Owner can tell you about that one.”
- “I…don’t really know.”
- “That one means that…” and then a story follows.
Usually I am perfectly fine with teams who write their so called “user stories” in a language that only they can understand. It’s their way of working. Their choice.
As a coach, I am there to spot improvement opportunities. And preferrably not even that. I’d rather ignite an improvement attitude in people so they will discover their own problems and find their own solutions.
And thus I ask questions. The answers I get tell me something about both improvement opportunities and people’s attitude towards improvement.
Whenever I find out that an entire team knows exactly what each and every one of their stories means, I ask them about their stakeholders. Do the people who benefit from the team’s outcome know what they get? Did they perhaps even write these stories themselves?
If the answer is a solid “yes”, then everything might be perfectly fine. Perhaps I am just a foreigner passing by. Perhaps I should learn their language to be able to help them more. Who am I to force them to spell out their full stories or worse…use a specific template.
However, I am always on the lookout for bad smells. Sometimes they are quite obvous, like in the first three examples I gave above. When team members refer to other people to explain their team’s stories or do not refer at all, then usually something is amiss. The team often isn’t a team at all. Just a bunch of people who work on their own stuff.
But…is it a bad thing? Is it bad if a group of people explicitly chooses NOT to be a team by having certain practices?
Not if they CHOOSE so.
Alas, most often it is not a choice. These groups usually call themselves “agile teams” and pretend to follow a certain way of working. Inadvertedly, for lack of knowledgde, skill, or intent.
So then I find the person in that group of people and ask her: “tell me what this story is about”.
What follows, always, is a story. A perfectly clear description of what is to be done for whom and why that matters. Sometimes it comes out immediately and in one go. Sometimes it takes a couple of follow-up questions. And usually some of the other group members stand by. Gasping. I can hear them think: “so that’s what that story is all about”. Sometimes they say that out loud. And when they do, I quickly become obsolete because an improvement dialog emerges among them.
But not always.
Sometimes nobody says anything. People just walk away when the story is being told. Or they do not even care to show up. They go back to “their” business.
Once again, if that is how the group chooses to work, I don’t mind. But when they still pretend, then I do mind. And then I provoke an improvement dialog. But not before understanding what is actually happening within that particular group of people. Not before I heard someone tell a real story.
Once an improvement dialog has been initiated, good things happen. The group starts being more aware of the impact of how they write their requirements. They can now choose to use stories as a form of requirements. They can now choose to tell real stories about what for whom and why. Then they can work towards real outcome much better than ever before. Valuable outcome. And they can do it together. As a team.
I wonder what the story behind the cryptic note on your post-it (or JIRA item) is…