Critiquing One of My Own Real User Stories

In case you haven’t noticed, a few months ago we launched Front Row Agile, a site dedicated to video training courses on agile and Scrum. This has placed me in the role of product owner for the site. And recently, the team on the project criticized my story writing! It was a valid criticism, so I want to share it here.

As you’d expect on a video training site, someone who buys a course is asked to review the course after watching it. Unfortunately very few course participants were leaving reviews. In fact, we’d only had one review given.

I looked into why this was so and discovered that when a course was complete, our on-screen request for a review was hard to notice. See the following image to see what I mean.

After seeing that, I added a user story to our product backlog:

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review.

And this was the story the team member didn’t like. He told me that this story made total sense for the participant taking action, but he said he would have written this:

As Front Row Agile, I want participants to be encouraged to review a course after finishing the course, so we can have more feedback about how folks like our courses.

The developer was right—there were a couple of possible problems with the story as I wrote it.

Jumping Right into How

First, the story I wrote bypassed what was needed and jumped right into how we would solve the problem. In general, product backlog items should start with the goal of the change being made to the system. The goal here was to get more reviews.

The goal was not a more prominent call to action. A more prominent call to action was how I thought we could achieve what we wanted.

However, I was very aware of this when I wrote the story and deliberately wrote the story to say how I wanted a change made.

I had already spoken to the designer about the lack of reviews, and he and I agreed that the call to action asking for a review needed to be more prominent. It would have been wrong of me to say I was open to any solution that achieved a goal of more reviews when I, as the product owner, had already decided on what I wanted.

I wrote this story as I did so that it would remind the designer of what we’d already discussed. If I’d written it in some more vague way, the designer would have wondered, “Is the story Mike wanted about improving the call to action to get reviews?”

Minimally, though, I should have added an explicit “so that” clause to the story:

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review, so that there are more reviews on the site.

Writing for the Right User

The developer also criticized my story for being about the course participant rather than about Front Row Agile itself or perhaps me as the site’s owner. That is, rather than start with “As a participant…” perhaps I should have written, “As Front Row Agile …”

I try to write stories that put the reader in the most useful state of mind for understanding the story. Generally, that means I’ll write a story about the actor in the story. In this case, Front Row Agile isn’t doing anything; the course participant is. So, I wrote the story from that perspective.

So Which Story Is Better?

This leaves us with the question of which story is better?

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review.

As Front Row Agile, I want participants to be encouraged to review a course after finishing the course, so we can have more feedback about how folks like our courses.

I’m going to fall back on the old standby answer of: “It depends.”

The “As a participant” story is better in the case where a product owner and team have discussed what is needed, settled on a solution, and the story is just reminding everyone involved of what has already been decided.

The “As Front Row Agile” story is better when the product owner is open to any number of possible solutions to solving a problem. If the Front Row Agile call to action asking for reviews had already been more prominent, I would prefer the second story above.

This would have shown that I was open to things like simply rewording the text, perhaps sending an email to participants after they finish a course, or perhaps moving the call to action to another screen entirely.

There are very few hard and fast rules in writing user stories. Even things like “write a story from the perspective of the person who benefits from the story” can best be thought of as guidelines.

What do you think? Do you have any similar examples?