Search This Blog

1 May 2017

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.

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.


30 March 2017

Meetup notes: An introduction to Scrum

Last night I ran a meetup introducing people to Scrum. Lectures are boring so I made it a game. At a rooftop bar.

Meetups in bars are best. Lucky it wasn't raining.

Agenda on the night

Tools I provided;
  • A printed copy of the Scrum Guide for each table.
  • A copy of my run sheet for the night
  • The picture from Wikipedia of Scrum
I organised people into teams of 3-4. People made this teams of 3-6. People were drifing in for up to an hour from the start time and we joining teams in progress.

The agenda on the night was as follows

1. Form teams, introduce yourselves to each other. Small teams work best. Take a photo of your team and publish it on the meetup site.

2. Focus you conversation tonight by coming up with specific questions your team wants answered.  You must write them down. Post a pic of your questions to celebrate the completion of this milestone.

3. Now, as a team, with the help of the scrum guide, the internet and the people in the teams around you, go answer your questions. When you are done, take a picture of  your answers/and your team celebrating success.

Why this format?

Learning works best when you pull (not push) information. Generating questions and hunting down answers mean the knowledge gained will be more personal, be better retained and be more useful.

Agile teams work best with clear goals and small teams. You practiced working this way.

Ideally you have all the skills you need on your team, but usually you don't. The activity provided this very problem and now you have experience solving it.

Meetups are about fostering a community of people who share with each other. Far better than having an expert stand out front while everyone sits quietly and listens.

It was fun.

What I observed

Most people didn't open the Scrum guide unless prompted. Even though a printed copy was on each table. This reinforces my views on oral traditions being the only ones that matter.

The activity surprised me by being a study on scaling work across multiple teams. Good will and respect for other people's time are all you need to scale. Anyone tells you anything else is selling something.

While most people professed to be absolute novices at the end of the night everyone pretty much said they had their questions answered and their goals for the night satisfied. I think I helped out with two answers and pointing two teams at the Scrum Guide.

So I think it was a successful meetup.

26 March 2017

An NPS Score for business analysts

I ran a second NPS survey on the business analyst community over this last summer. I didn't get nearly as many responses as the last time. (Here is the results of the last survey.)  Below is the analysis from this survey.

Why do a survey on the BA profession?

For me it's a hangover from earlier work with Business Analysts, as well as a general interest in whether the 'BA profession' is changing now that the IIBA is operating to bring people together under a bunch of standards.

So my questions are;

  • Is the BA profession getting more valuable with it's certifications, training and industry standards?
  • Does the introduction of an industry body and standards make a difference to the quality of work people do?

The Survey form

Apart from Demographic question the survey was very straightforward.
  • On a scale of 1-10 how valuable is the contribution of the BA you work with?
  • Why did you give this score?
  • What is your role and industry
  • Who are you customers
The survey doesn't target business analysts as the respondents. It targets the people that work with business analysts.

The survey went out to people via Linkedin and Twitter and ran from December 16 to Feb 17. There are some natural biases in the participant self selection process, but I won't dwell on them here.

The responses

I got 21 responses (last time I got over 100) which I think is partly the result of
  • My diminishing social media presence
  • When I ran the survey
  • The shift in people on agile teams from BA to Scrum master or Product Owner 
  • less people I am connected with on social media are working with business analysts (for example, I no longer work with any)
21 is still a response though and gives some insight.

Almost all the results this time came in from Oceania (Mostly Australia) with just a handful from North America, two from Europe and one from Asia. The American, Europe and Asian results all called out their experience with business analysis as highly positive with advocate level scores.

The NPS scores are represented in the chart above. You can see only one response giving a score of 4 and 5. The majority of scores are between 6-10. In NPS parlance however 6-8 is not good scores. Up to 6 is a negative score. 7-8 are neutral. After all the instrument is measuring how likely people will advocate for your service, not just whether they are satisfied.

Key themes that came though in the comments include the following;

The business analysts people valued did the following
  • Focus the team
  • Ensure goals were clear
  • Partnered with product and software people to prepare and organise the work
  • Organisers of people and knowledge
  • Measure both he product's and their own performance 
Business analysts that were not valued did the following
  • Put process and methods ahead of the work
  • Focused on tasks and transactions rather than value
  • Focus on features rather than the whole solution (eg performance, reliability, security etc)
  • Don't have confidence in their own contribution to the team
  • Don't have real domain knowledge
  • Don;t have real decision making authority

The insights and hypotheses

Your NPS is Three
The first result to note from the results is that the NPS was three. This is up from -six last time I ran it. Don't get excited though the difference in scores could just be the different people that responded. 

If we filter out the non-Australian results we see that the Australian industry generally finds Business Analysts more trouble than they are worth, potentially contributing only administrative and commodity level contributions.

There might be something there though. Things might be getting better. When you read the scores there is less frustration with an overly dogmatic pursuit of process standards and templates. See more below.

Agile teams and business analysts
Additionally there wasn't much chatter about process over content. It looks like that part of the discussion is outside my network or else a mostly solved problem. 

There was a clear sense that 'agile' teams are happier with the contribution of business analysts than non-agile teams. 

It also looks to me that people are doing other roles (eg agile coaching and scrum mastering) on top of the BA work and that the work that lives in those job descriptions is what is being valued.

Perhaps what the BA is doing is leveraging their process knowledge and facilitation skills and aiming them at the delivery team rather than the customer/client. Where I saw the BA being valued there was also often mention of a Product Owner" being on the team also.

Being there
There are obviously issues with the set of respondents. There are biases based upon my network, my geography and the way people select themselves into this survey. There are trends in this response set that probably aren't global, but they probably do represent an industry trend.

What did I learn?

The BA as team coach model is one I have always though wrong based on my notion of what a BA is and should be doing. Maybe that doesn't matter. If talented people can bring skills to bear in a useful way, maybe that's the important thing and job titles are irrelevant.

Further questions

  • What happens of we make this survey really global
  • What happens if we solve the agile bias in my network?

Call to action
Would you like to help me run this survey again next time? Put your name below or message me. I'll be in touch when the time comes.