Episode 5: What’s the story, morning glory? Principal Product Manager Dan Corbin and Mobile Engineer Michelle Cervenka discuss why the best users stories are never finished—and how to start the conversation between product managers and engineers.
Full transcript below:
Chandra K. Bricker: Hello and welcome. I'm your host Chandra K. Bricker and this is the Staple and Fancy by H-E-B Digital podcast. Today on the mic we've got Dan Corbin, a Principal Product Manager, who also likes to go by the Grand Poobah of product management, and Michelle Cervenka, principal mobile engineer. How are you?
Michelle Cervenka: Good, thank you.
Chandra K. Bricker: I was so excited to have both of y'all in the studio today. We are here to discuss what makes a good user story. So, Dan, I know that you've got some strong opinions about what makes a good user story and a formula that works for you. When I ask you that question, what's the answer that comes to your mind?
Dan Corbin: I think—well I'll give you what the kind of pure Agile answer is. There's a way that people describe user stories, and there's an acronym SMART—they're supposed to be specific and measurable and actionable—and those are great guidelines. But, I think, when you are working with engineers the most important thing is to give the engineers clarity, context and to keep the focus on the customers. I think that is best done by using the formula of "As a [blank user type] I want [talk about what is the feature and the functionality that you're looking to add] so that I can [blank]." And that last piece, that customer value that is being delivered, is really important. And as a product manager, I like to focus on that piece the most because I want my engineers to be customer-centric. Also what I like using that formula for writing user stories is it keeps me as a product manager out of the "how." Hopefully, it gives the engineers enough context so that they can start asking me questions to get a better sense of how they might approach it and tackle the problem.
Chandra K. Bricker: Well I've heard you say that a good user story is the beginning of a conversation between you and the engineer. Do you see a user story as something you create and handoff or?
Dan Corbin: No absolutely not. You really don't want to try to put too much detail into a user story. It really should be fairly short, concise, clear. I think the value comes in the discussions that are had with the engineers about what you're trying to accomplish and why.
Chandra K. Bricker: So Michele if you get a user story that says "as a user type I would like to do X so that I can achieve Y" is that enough information for you? Or what are you looking for?
Michelle Cervenka: Well that's definitely some of the information we need. We also look for acceptance criteria to help know how will we know we've achieved this goal. How do we test it? Is this a small amount of work that we can estimate (normally you like to complete a user story within a sprint)? Dan's right—this is the beginning of a conversation. You want to be able to look at a user story and know that this piece of work has been defined, and yes we do have a story on it. You need to be able to read and understand it very quickly.
So I work on mobile, which is front-end, and normally by the time a developer gets a user story and is ready to work on them, it comes with some amount of UX—you know wireframes or Zeplin design. So this helps communicate the objective to a front-end engineer, but with that conversation that you have with the PMs and UX, you are making sure that you have all the assets you need. If there are any edge cases, does the developer understand? Because, in the end, the developer is making all these little decisions—what happens when an error occurs? or what if I don't get data? So the better the developer can understand the user that they're supporting and the benefit that they're trying to achieve, the better decisions you're gonna get from the developer.
Chandra K. Bricker: But isn't that counterintuitive? So if I want a developer to completely understand what my customer needs, doesn't that mean you write a longer more detailed user story?
Dan Corbin: No, not necessarily. I think it's nearly impossible to write a perfect user story that encompasses all the edge cases. I think Agile is powerful because you are using all the information that you have at that given moment. And you work iteratively, so by using that approach with engineers and having that free flow of discussion you're you get a much better end result, especially because things will come up in the creation of whatever you're building that the engineers will kind of come back and say, "well we didn't think about this." That's how user stories get improved and you end up with a better result. It's that collaboration between product and engineering.
Chandra K. Bricker: Back and forth rather than one and done.
Michelle Cervenka: Normally with a user story come other user stories and that conversation gets more detailed.
Chandra K. Bricker: Are there are key elements that you can look at a user story and say "This is a good one, this isn't"? Are you looking for specifics? Say if you had to make a checklist.
Michelle Cervenka: We have made checklists in the past. I think depending on your group it drives how detailed people want to get and how comfortable they are with taking a ticket and working it. For UI: it comes down to do we have a UX design? Do we understand the flow of data on the screen? What happens when they click this button? What happens if the data is in this state and then they click this button? We would like to have a user story that's defined within a user flow. We need all the assets that make up that screen, the error messages or copy for the screen, and then the acceptance criteria from the original user story.
Chandra K. Bricker: And are you the only person who receives a user story? Are the developers the only people who are on the receiving end of that?
Michelle Cervenka: There are many consumers of a user story. We've got the developer, the other developer that's reviewing the original developer's code...
Chandra K. Bricker: Developer number one, developer number two.
Michelle Cervenka: We have the tester. We have other teams that are trying to understand what other squads are doing.
Chandra K. Bricker: So more people are listening in on this conversation between the product manager and the engineering developer.
Michelle Cervenka: Yes, for sure.
Dan Corbin: And I think it's important that you try to make those discussions transparent. At H-E-B were big users of Slack, but you also want to make sure that you're tying your Github commits back to tickets so there is a track record of what actual changes were made, and you are also leaving appropriate comments and tagging people. There are a lot of effective ways to make sure that everyone is part of that conversation.
Chandra K. Bricker: How do you know when you're done?
Dan Corbin: [Long pause, laughter] I would get….So going back to like the Agile purist, you have a demo. The product manager signs off. And how that is actually done differs from team to team, but there does need to be essentially some sort of review or demo and agreement that "Okay, great we achieved this." And then you also will have that discussion of like, "Okay, what did we learn in doing this work? Do we need to create any subsequent cards? Or, based upon this work, can we remove cards from the backlog?"
Chandra K. Bricker: How involved do you get in grooming the backlog?
Michelle Cervenka: Normally engineers are pretty involved with grooming the backlog to make sure that there's enough information to estimate that all the things that I mentioned in the checklist are being included in the tickets, and having an input order, importance…
Chandra K. Bricker: The prioritization of what comes first…
Dan Corbin: I think the one aspect we haven't touched on that we probably should is—writing a good user story also helps the engineers understand the scoping and how to best point the work. Knowing how much effort is going to be taken, what is required for each of the stories, helps you—well, me, actually. It helps me as a product manager determine how much I can include when I'm doing my sprint planning.
Chandra K. Bricker: So going back to this original sentence “As a [user type] I would like to [X] so that I can [Y]." How many different lines do you put in? Like I can imagine that this gets pretty big. "I would like to do XYZ-ABC-LMNOP so that I can and then a laundry list of a bunch of other things." How do you keep it succinct? Or do you even worried about it being succinct?
Dan Corbin: You definitely worry about it. What you want to do is try to break the work down into small chunks, as small and independent chunks as possible. Because that is going to allow and really feed into the iterative process. But it allows the engineers to really improve their flow and get more things done. If you have user stories that are just too large, they tend to drag on, and it will hurt the overall velocity of the team. I think it's one of the big challenges that product managers have is to really work with the engineers to break things down. It can be hard to do that, and it takes effort, but that upfront effort will result in better team performance.
Chandra K. Bricker: We talk about this: How do you need an elephant? One bite at a time.
Michelle Cervenka: Keeping it small really also improves the quality of life for developers. We all like to check things off our list, and so you give that to the developers. "Okay I've gotten that done. I've moved it across the board. I feel good." And then you move on to the next one. When you have a ticket that's open for a long time, it's got a lot of complications or you just don't understand, it really kind of drags the developers down.
Chandra K. Bricker: Oh yeah I can imagine. Is there anything else we should tell our audience about what a good user story needs? Dan you teach classes on this?
Dan Corbin: Mmm-hmmm. No I think we covered it absolutely and completely. [Laughs]
Chandra K. Bricker: In small bite chunks.
Dan Corbin: In all seriousness, it is something that takes time. And you will see as teams mature, they get better and better. You really should put in the effort. Dedicate time to grooming. Make sure that the entire development team is involved. Use your retros to figure out where your user stories went right and where they went wrong. And really just continually seek to improve as a team, and that really will lend itself to higher performing teams and a better quality of life. Because Michelle's point is very true if you get stuck on something and it just becomes a grind it really will drag, not only individual engineers down but it'll slow the whole team down and that's what you want to avoid.
Chandra K. Bricker: Absolutely, it’s a craft and the more you do it the better you become. Agreed?
Michelle Cervenka: I agree.
Chandra K. Bricker: Wholeheartedly. [Laughs] Well thank you both for being on the mic today and that is Staple and Fancy by H-E-B Digital.