I'm here with Greg Cohen, author of Agile Excellence for Product Managers and 20 year product management veteran. Thanks for joining us, Greg. >> Thanks, thank you, Alex. >> So, let's talk about user stories a little bit. What are your top five most common recommendations about the creation and the use of stories in the Agile process? >> Yes, I think, for me, the most fascinating thing about the user's story is that it's a really open ended framework. So it can be used well, and it can be used poorly. And I think the single most important thing is keeping the user's story in the problem space. So that it facilitates that important discussion with the team, so the team can reach a shared understanding of what that problem is. And then together, conclude what is the best way to solve it for the user. So I think that to me, if I can just really narrow it down to one, it's moving the story from the perspective of just the problem, and don't put the solution in it, leave that for the conversation. >> Got it, that's great. Anything else on stories, that's a great one. >> Well, certainly, I think the one thing that gets missed a lot is that conversation. People feel that's the documentation, we can just hand it off. >> Yeah. >> And, once again, that's the most important piece. Or I think that's the most important part of the process, is you have that conversation. If we think about documentation, there's only a real few uses of that, right? One is to create shared understanding for the team. Another one can be to actually document decisions. And the third, sometimes it's required as a regulatory requirement in the industry with which you work. But when we think about user stories, its sole purpose is the first one, how do we get to a shared understanding of what the problem is and then how we're going to look to solve that problem. And that's the acceptance criteria, when do we know that we're done with this story? >> One thing I find myself working a lot with students is when we dive into a story or a problem space, getting to the right level of detail with the stories and kind of nesting child stories under epics. Do you have any suggestions on how practitioners can both help themselves and coach the rest of their team to really unpack the detail around the narrative that they want to discuss? >> Right, yeah, no, great question. I think this goes back to our earlier discussion here, right? Learning new skills is hard. So just because the framework for a user's story is simple, gaining mastery of how to best use it is challenging and difficult. And it takes time and experience and practice. So the biggest thing is just, once again, start high, keep it in the problem space. From there, a lot of conversation and discussion should emerge. And those each can be raised to break down that story, right, in the ways to split it. I often find for me the easiest way is I list my acceptance criteria, and we work on that as a team. And then each of those can usually sit alone and stand alone as its own story. So when the acceptance criteria gets too long, more than five or seven items, I know it's time to split and decompose that story further. >> Got it, okay, that's great. >> Can I get one more point? >> Yeah, absolutely. >> All right. I think the other thing too to realize just about a feature is that features have life cycles. And there are times when you're looking purely for proof of concept, or feasibility, I'll call it, right? Can we technically implement something? That's one piece. Another one would be that I need this to get done, so I can bring feedback to the team. We need to be learning here. A third one is often we're just polishing something. And a fourth one would be that there is a real time constraint, and I think you need to bring that too into that story process, as well as, what do you want to accomplish at that point? >> And where does that come into the process, is that kind of a charter for a meeting where you discuss the stories? Or how do practitioners- >> Yeah, maybe I jumped the gun there. That's sort of a lot on the prioritization. But for me, that is also another, that prioritization dictates how you would split and decompose a story. >> Okay. >> And when you want to actually attack that problem of decomposing the story. >> Okay, got it, got it. >> If that makes sense. >> Yep, yeah, sure. And how do you, as a product manager, how do you create a good environment for the creation and the discussion of stories? >> I think it's carving out the time to meet with the team and socialize them. And often, I think it works best or at least I find it works best meeting with the small group of people that's interested in that specific story. So it's not that we have to bring the whole team together all the time and have people sit through stories they're not interested in. It's about letting people know we're going to talk about these stories or maybe already know the section of a code they're working with. And I go and approach them and socialize them, and socialize them early. It's that grooming process before you get into the real planning and also work with the QA people. So their voice gets heard in the process as well. because they're going to come up with questions about how do I test this, that myself or the developer will not. >> And with the life cycle of the stories themselves, we have this idea of an informative workspace, we have boards, or places where we look at the work in progress. Do you have any practices that you've seen work well or not well with regard to keeping the stories visible and keeping the problem in the foreground, in people's minds, so they're focused on what's valuable to the user? >> Right, yeah, so the technique that I find myself just turning to more and more and more is Jeff Patton's Story Mapping. >> Uh-huh. >> And in this case, what we think about the traditional user story, actually, their goals go up in the x-axis. What they're trying to achieve and then the different personas can sit out sort of on the left, separate of this, so the story gets decomposed. Persona gets taken out into its own area, what their goals are and then what is kind of a task or feature that they're trying to achieve or, in there, and that goes in decreasing detail beneath the goal. And this gives you a two-dimensional view of what the user's trying to do, and you can take any persona and walk them through the map. And see do they have the features that they need to complete the task and larger goal. For me, that's the best way to frame it, and then you can split those story maps by release, so the things that sit up higher are in the first release, things that sit down lower are in the second release. And from there, then we take those and we decompose them into smaller stories. Because I think maybe the point that you're alluding to is if you just have a linear list of stories and they're in all different granularities, you lose context of how does this story really tie back to the larger goal. >> And what's your point of view on the relationship between stories in estimation? Are you a no estimates guy, or are you a planning poker shark? What's your view about what works there and when? >> All right, yeah, I know this has become a real controversial topic, and for me, I approach this from the product management side. For me, the estimate is very valuable. It's the first indication I have of what the cost of the story is for solving this problem for the user is going to be. And in my mind, I have an idea of what kind of ROI I want to get out of this. So it's not just how much value I can create, but it's also what is it going to cost me to create that value for the business side of this product and managing this product. So for me, estimates are really important. But what has worked well is planning poker is an excellent way to teach people estimating, it's an excellent way to share knowledge amongst the team, but it could be time consuming. I had this one team where I just went to the team lead, and that was a team that really had an amazing mental synchronicity, it was an XP team. They were doing para programming, so knowledge got exchanged during the programming process and got shared. It didn't have to come through the estimating process that we use. So I would just speak to the team lead, and he would very quickly come up with an estimate that wasn't an arduous or time consuming process. But from there, I understood the cost, and if it was too expensive, we could have the follow-on conversations about how might we achieve this user goal. Or think about it differently or work out the problem in a different way to get the same end result. >> Got it, got it. And what relationships do you see between the quality of these user stories and their impact on the quality of the narrative collaboration that happens and just the general effectiveness of their backlog process in the team? >> So I think that, we talked about earlier, you gotta keep the story in the problem space. And if you do that, even poorly written stories can still, they self-correct. As long as it drives the right conversation, the story gets refined and clarity comes to the team. The time where I see stories maybe being an impediment to progress, is where they're written in solution form. >> Mm-hm. >> Where you just specify this is the feature. And in that case, at that point, you cut off discussion, you cut off creativity, you cut off the ability for the team to think about alternate ways to solve it because they may not fully grasp what the problem is that the user's trying to solve. >> Got it. That's some great ideas on how to bring narrative collaboration into the practice of Agile and how to make it really work in practice. Thanks, Greg.
