Writing Better User Stories
The patterns of a product owner writing user stories for software development teams is an opportunity to be improved upon.
On Tuesdays at 11am, Mark walks over to the round table near the window. The team see he is ready and wrap up the tasks they are on. Justin heads over to the kitchen and grabs a fresh water. Jerome grabs the two index cards that are still in play from the whiteboard and brings them over to the table as well. Zoltan grabs some sharpies and a stack of post-it notes and walks over with David. They sit around the table.
I walk across and ask if I can sit in and observe the meeting.
Mark plays down six index cards onto the table like a blackjack dealer. Unlike blackjack the cards are all face up with Mark’s almost legible scrawl on them.
Mark picks one of the index cards up and starts reading it to the team. There is a back and forth across the table about why this user story, how does it help the customer, and how it might be implemented. After about 6-7 minutes a consensus is reached and Zoltan grabs the card, flips it over and writes a few acceptance criteria on the back, reading them aloud to the team as he writes. The other software developers on the team chip in with minor adjustments to the phrasing.
By the end of the session, all six cards have been accepted into the sprint and each of Mark’s index cards have also been marked up with the handwriting of the team members on the back.
The guys started to shift, getting ready to get up and head back to their desks to get a little more work done before heading out together for some Korean Fried Chicken (and beer.)
“Hey, before you go, can I ask a couple of questions?”
Everyone settles back into their seats and look at me expectantly.
“It’s interesting to me that each of you on this team have written on the cards. You all took turns to write up the acceptance criteria. Why is that?”
“Well,” says Justin, “If I write the card, then I know what I mean. If someone else writes the card, I have to struggle to remember the details of this conversation and probably have to repeat most of it in three or four days’ time.”
“It’s just easier this way” says Jerome.
“Cool. When did you start doing this?”
“I can’t remember. It just started one day. It didn’t come out of a retro or anything, but we did used to talk about how often we would repeat the user story discussion over a week or fortnight,” said Jerome.
***
There are fundamental reasons why this practice of shared story writing is better than having a product owner or business analyst be the one to exclusively write the user story cards.
Think about your own experience listening to others.
Your attention wanes in and out. You remember parts but not the whole of conversations. And the things that stand out in your memory the most aren’t necessarily the most important things.
However, when you take notes things change. For a start you need to make choices about what to write down. This makes you think about the content in more than one way – you are listening to it, engaging with the idea behind it, thinking about which points you want to focus on in your notes and also choose the words you use to represent the idea. Finally, your body also has to contribute to the note taking. Your hand moves a pen across some paper. Your eyes then read it to confirm what you have written is correct, and then you process the idea again.
All of this is going on almost simultaneously.
As you can see your brain is working much more when taking notes than just listening. This means that the memory around your idea is being imprinted much more firmly in your head than if you had just been listening, or even if you have been engaged in a discussion. You are creating multiple connections in your memory to the idea through these interactions and transaction.
Note taking is a powerful tool when trying to understand and later recall an idea.
(A side note; the act of physically writing appears to be a more powerful tool for understanding and remembering than typing. Even holding an index card improves understanding more than reading a screen because of the same multi-sensory processing going on.)
***
“Nice. Let me ask you another question,” I said. It was almost time to wrap up. The fried chicken was calling. “If this is a good practice, what would make it better?”
The team looked across to Mark, the product owner. A pause. Everyone thought for a moment. One of the guys was chewing his inner cheek as he thought. Zol twirled a pen around his finger. Then David, the team’s designer spoke up.
“We shouldn’t let Mark touch the cards at all.”
Mark was confronted by this idea.
“I don’t feel comfortable with turning up without cards to talk to.”
“That’s okay. You bring your cards, but we will rewrite our own.”
***
There is another opportunity in writing cards rather than receiving them. Can you guess what it is?
Imagine this scenario;
We sit at the table described above. I’m the product owner and I hand you a card with my user story on it. I tell you what the customer goal is, their motivations, the constraints and related rules around the user story. You listen attentively. It seems kind of obvious. You ask one or two questions about what I explain.
At the end of this discussion, because I am diligent I ask you; “Do you understand what needs to be done?”
You give a short nod affirming you understanding and head off to do the work.
That sounds straightforward and simple, right?
Now imagine this scenario.
Same job, but this time I hand you a pen and paper and you write the notes. I still tell you the same things but this time you are actively asking questions and drilling into what I am saying because you are writing notes down. You choose the description. You use your own mental models to frame the written description. And at the end you say what you understand the job to be, by reading out what’s on the card.
Which of these two scenarios is going to better equip you to go away and do the work?
***
Mark and the team tried the experiment and it was useful for a while. Over time they vacillated between Mark writing cards and the team writing the cards. They are a tight knit group and these days anyone writes whatever needs writing regardless of role.
There was one last effect I saw as they played this out, and it isn’t specific to the technique. It’s more about the people; By putting the card writing in the hands of the delivery team it put responsibility into their hands to pointedly and specifically ask “What’s in this for the customer.” Over and over again they guys asked that question. They were always very customer centric, but they were no longer being told. They were actively asking. That helped the knowledge acquisition and it helped memory and focus. It also helped with prioritization and managing scope better.
***
It’s funny. People like to find patterns and follow them. Inherent in high performing teams is the need to go farther and do better. The job isn’t done when you have your requirements on a pin-board and can ship features fortnightly. You don’t follow a manual.
The fundamental thing about this agile movement is learning through doing. You inspect and adapt. You ship and get feedback. You collaborate, deliver, reflect, and improve. You explore and learn. And that means experimenting and researching.
The scientific theory behind these ideas idea is pretty well established, although there is debate about how to make the most impact for memory. And it’s intuitively true to most people when you describe the ask over tell mode of communicating. Most people just get it. Still, people don’t change their habits without expending their limited energy.
To help you shift I want to ease you in with a low-cost experiment.
Share this post with your team mates and talk about it together. Propose that you all run the new card dynamic as an experiment in your next sprint. If your Product Owner is currently writing ALL the cards, maybe take the first step of just taking over acceptance criteria. But why stop there. It’s an experiment. You could just take over the whole card writing thing and give it a shot.
Then, at the end of each week, maybe for two sprints, talk about whether the new card dynamic has paid off in any ways.
***
Here are some links to more on this topic in case you want to go deeper.
- MakingMemories
- The way we think shapes the way we understand
- Writing things down yourself is better
- Weare also addressing confirmation bias in this story
Some details of this anecdote have been simplified to make the point, but this is a real case study with a real team.
As always I love to hear feedback if you try any of my ideas out. Comment below, tell me direct etc.
Thanks for reading.
Leave a Comment
You must be logged in to post a comment.
