Event Recap: Boston PMs share Real User Stories
Last night, Product Managers from Twitter (Oliver Young), AppNeta (Jennifer Burner), and Ecovent (Kit Will) generously shared real user stories they’ve written for their team. We asked them to bring a bad and a good story that they’ve written and explain what makes a good user-story. The event was really well attended and I thought people might be interested in some of the findings that I understood from the panelists.
- User stories are different across different teams
- Good user stories highlight a clear user value
- Written user stories don’t replace conversation
Note: Even more interesting that my recap are the slides from the actual event which I’ve posted here.
1. User stories look different across different teams
If we didn’t know this before, the event last night shed some clear light on different user story writing styles.
User stories are ultimately a tool for communication. Different circumstances like team size, location, product maturity, and communication styles all effect the amount of written communication required. For example a 4-person team like the early days at EcoVent could use one-sentence jargon-y stories because when engineers, designers, and PMs looked at those stories, they all understood what needed to get done. Even when it looked like this:
But a complex feature and a remote team might need more visual story with a lot more supporting context
Oliver Young uses images, example scenarios, and lists to communicate with his international team of engineers:
Jennifer attaches interactive prototypes to Jira tickets
2. The best stories clearly outline a user value
Each panelists spoke about this. Ultimately engineers need to understand who they are building for. This means a clear outline of user value. This can be accomplished with a business case in the user headline on a small team like EcoVent’s:
But I loved learning that Jennifer actually uses direct quotes from user interviews or recordings of live user sessions to show developers where the pain points are that her stories are addressing:
User stories don’t replace conversations
Each panelist spoke about conversations in addition to written requirements. The “good” stories included mock ups, prep conversations, and follow up conversations. Writing something down and sending it around was just not enough. Communication went beyond emails and tickets.
Jennifer brought this up early on. She meets with a designer and technical lead early on in her process to discuss how the stories will be organized and written. Then, her team organizes weekly Story Telling Hour, which she said, “is a lot less fun than it sounds.” The goal of that meeting is to review and discuss user stories.
Oliver travels to spend time with his remote teams and prefers conversations over story-writing. Despite being an english major, story writing is one of his least favorite activities.
Kit shed a lot of light on the pains of teaching a growing team old jargon and questioning the writing of old assumptions. As start-ups grow, they switch everything from their User Story style to even adapting new tools like Jira.
These teams clearly value utilizing a variety of communication tools; in-person and remote. A great user story doesn’t live in isolation. Hopefully we can explore some other important PM tools and styles in future Boston Product events.
