Getting from an Idea to Actionable Backlog

The Gaps in Your Agile Methodology No One Talks About – Part 2 Where Do Stories Come From?

Webinar Synopsis

So, your boss instructed you to “just write all the stories,” but you have very little to start with beyond a vague idea or a bullet point on a slide. How do you get from this humble beginning to those brilliant, right-sized stories that can be handed off to your developers?

Illustrated via real-life examples, Anne Steiner demonstrates concrete steps for filling the gaps between idea and high quality stories. Not only will you have your stories but, more importantly, you’ll have insightful discovery conversations that lead to deeper and more meaningful product understanding!

Webinar Recording

Webinar Slides

View the slides here

Webinar Transcript

Myriam: Well, good morning, good afternoon and good evening to all. Welcome to part 2 of our series of webinars on The Gaps in your Agile Methodology No One Talks About. Our topic today is Where Do Stories Come From: From Ideas to Actionable Backlog. My name is Myriam Sanie and I’m with the marketing team here at cPrime. I’m very happy to be welcoming again Anne Steiner, VP of Product Practice at cPrime. Thank you so much for being here with us. And now I’m happy to pass the baton over to Anne. Take it away!

Anne: I’m pretty pumped to hang out with you guys here in Part 2 of our series of 3 webinars where we’re going to really dig into one of the deep questions plaguing me for over a decade of my career: Where exactly do stories come from? Just a little bit about myself and about what we’ve been doing here with this webinar series. First of all about me. I started out as a front end developer, spent about 10 years actively coding back in the day and C++ and Java. I was just chatting with a colleague in the industry the other day and we were joking about how you can almost tell how old someone is by when they tell you what their first object oriented language was. I was relieved in that conversation that his was small talk. So I felt better about C++ but from there, you know, after spending some time coding, I really had a desire to get closer to the customer and to see more impact to the problems that we’re solving.
So, from there I transitioned more into a product owner role and ultimately a product management role, spent about three or four years working directly with teams as a technical product owner, being that person that was in the trenches everyday writing stories, getting ready for the sprint plan and doing all those types of things. Later I got to work as a product manager and ultimately as a product line manager. Then I had this really cool opportunity to start doing some product coaching. And so, you know, I jokingly say that I’m now four years in recovery from being a product owner and getting to do some really cool stuff working folks like you. I’m talking about stuff like this. So I’m really excited to be here and I thank you all for joining us in this webinar.
Today we’re going to really focus in on how do we create that product backlog. Alright, so this is what you’re going to do today. It will be a quick rundown and these four points and let’s go ahead and jump into it. So as we talk about where do stories come from? You know, when I first transitioned from being that developer and the next day kind of being the product owner, I learned pretty darn quickly as my job to bring the stories to the sprint planning and okay, that’s cool and all. And when we think about user stories, you know, typically we were going to think about something that’s that small, independent, testable, valuable thing that’s written from the user’s point of view.

Often, especially if we’re rolling on those standard two week sprints, that thing needs to be able to fit into a sprint and for it to be able to be completed, developed, tested, some design artifacts, those type of things to get done within a sprint needs to be about three to five days. So if we’re starting with some really, really vast, huge idea, maybe something that’s just a bullet point on your roadmap or something the big boss asked for, how do we get that idea broken down and understood enough that we’re able to get it to those three to five day stories. And personally I really, really struggled with this and coming from the tech side, I tended to work from the bottom up, I’m thinking about the technical tasks that I would have to complete as a developer. That was a really bad strategy because it was fragmented.

It didn’t necessarily roll back up to that idea. So then, you know, you start taking some classes and stuff and the pundits in the industry say, Hey, this is easy. No problem. Okay, all you do is you take your idea and you’re going to break that into smaller things that are called epics and then you’re going to break those epics into stories. So pretty easy, right? And I said, well, okay, but how do you know what the approach should be? And then I was told, hey, you know, you just kind of just go ahead and brainstorm these things on a note card and boom, boom, boom. Then you’ll have your epics. I had a hard time buying that because I don’t think it’s as simple as just brainstorming things on a note card. So I spent a number of years trying to get to a point where I felt like it was a good answer to the question. And I’m happy today to be able to share one of those answers with you.

So what we’re going to talk about for the remainder of this Webinar is going to be how do we get from one of those bullet points on that roadmap items down to those stories that you can feed into that sprint.

So let’s think. I want to draw this picture for you in a little different way. Now, if we start with a product idea or a roadmap item, I want you to kind of think of that almost like a funnel we’re in. As we go down this funnel, we’re going to work through a number of different practices that are going to help us to narrow in focus. And in the end what we’re going to end up with is actually an ordered and a sized list of things. And you can think of those things as things that we’re going to do. But I’d like to think of them as product choices or places that we plan to invest. This funnel is going to help us not only narrow into focus in, to make product choices, but it’s also going to help us, as a product team,gain a common understanding of what we’re building, why we’re building it, and who we’re building it for. To get a big picture view of what it is we’re trying to accomplish and what experience we’d like to provide to the user. But to do all of that in a manner that’s, low ceremony, low fidelity and can happen in the course of hours or days versus weeks or months, I’d like to kind of call this journey on this funnel, early product discovery.

There’s a lot of different ways and different practices that you can apply kind of on this journey. What we’re going to talk about today is going to take us down this path here. But there’s other ways you can see it. I’m right here in this picture. And then there’s many different ways that you can do this that, you know, we haven’t even included in this picture. This is one option. It may or may not be the best option, but I’ll tell you, it’s an option that I’ve seen work over and over and over again. So it excites me because it’s like finally I’m real steps that fill in that question mark that I showed you two slides ago. I’d like to walk you all through this in the context of a real life example. And in an early discovery session that we facilitated with one of our clients and that client is called the bridge for youth and they’re a shelter located in Minneapolis St Paul Metro area, that helps youth that might find themselves in situations where they need help.

And the bridge for youth is in a coalition with a bunch of other shelters in the area called the youth services network. We created a mobile APP for that network that basically allows a youth that needs help to be able to connect with different resources in their area via a mobile App. So, that’s called the YSL mobile App. We’ve been working with the bridge for youth for a number of years, helped them to kind of build the initial version of it. Nut in the story that I’m about to share with you, we’re actually looking to together scope out, understand let’s call it the 2.0 of that mobile App. They had a couple of different things that they wanted to accomplish with the session. First of all, they want to understand how could we take the success of this mobile app had in the Minneapolis St Paul Metro area in roll that out throughout the state of Minnesota.

So, they needed to enable some different capabilities to allow for that. Also during the course of their first release and it’s starting to be used in the field, just discovered some pain points. They were getting feedback from users, both their staff and as well as youth that were using the mobile app, that there were things that were clunky, there were usability problems, there were some bugs. And then last but certainly not least, we wanted to use this discovery session also to understand enough about the scope and what we’re attempting to accomplish. So that they could submit a grant application and it kind of thing of a grant application and a lot like a traditional project plan where you’re being asked to very early on committed time, budget and scope. So we wanted to do that in a manner that would allow us to test and learn and to be a little uncertain as we go, but to be certain enough to provide enough detail that they will be able to get this grant.

This story that I’m going to tell you played out over the course of two days, and these are the steps that we took. We did collaborative framing, persona story mapping, a design studio, customer journeys, and ultimately wrote stories and tasks throughout this. We’ve also created about a 12 to 18 month roadmap that would have future releases as well. So I’m going to walk you through the experience that these folks had from getting from that idea, these first four bullet points on this slide, all the way to getting the stories it could be fed into a sprint. And you know, just to remind this played out over the course of two days. All right, so where do we start in that first step on the funnel you remember was something called collaborative framing. And collaborative framing is nothing more than a conversation, a lot of it feels almost like a traditional project charter project kickoff, if you’ve ever been a part of that. The team’s going to come together, they’re going to name the initiative, select a timeframe for it, really dig into what are we doing, why are we doing it, and who are we doing it for?

We’re also going to define goals and success measures in picking a group of things that we truly believe we can accomplish over the timeframe that’s been established. So kind of similar to a project charter in that manner where it’s different than a project charter is in collaborative framing. It’s really about the conversation we bring together, ideally the whole product team, but if that’s not feasible, at least a group of people that can represent what’s valuable, what’s usable and what’s feasible. And we start from this common starting line to make sure everyone has the same information in the same understanding. Oftentimes in that traditional project, charter world, maybe the project management lead and the product manager that sat together for weeks ahead of that meeting and created an extensive PowerPoint deck and then they came into the meeting and they gave the PowerPoint presentation to the audience and you know, had about two minutes at the end.

So, if there are any questions. No one did, of course, and then everyone left, right? And in that scenario it was more about the artifact and kind of checking the box. It was about that PowerPoint. When it comes to collaborative framing, it’s more about the conversation and the people having the understanding. So, you’re going to walk out with an artifact. But that’s the less interesting part of this. Collaborative framing is also that first chance in our journey to start to narrow into focus. So we can make product choices, will encourage teams to pick a pretty short timeframe, maybe three to four months, maybe even shorter if your release cycles can support that type of thing. So that we start to really focus on, okay, what can we accomplish over the shorter time frame? And that’s going to simplify the problem, the analysis and the understanding right out of the gate.

One of the things we also talk about during collaborative framing and I forgot to mention is our design targets and these would be the people or groups of people potentially even market segments that we wish to impact. So the next step from us to really dig into those design targets and ask yourselves who are we building it for and get to know those people. In this case, we used a tool called pragmatic personas to help us to understand the primary design targets of the people that would use the App. Here you see two members of the product team. I’m working through a persona exercise together. A lot of you have probably done personas. It’s a very common practice in the user experience community. This version though is intentionally lightweight, and a super low fidelity, but it just gives us that opportunity to have a conversation, make sure everyone knows the same things about your users and then to reveal places where maybe we’re making assumptions or we have questions that could help lead to focus research. So they’re thinking about those designs, those personas, they’re reading down, you know, a description for those personas, things at that persona values, especially with respect to the use of the software and also goals that the persona has. What are they coming to this product to accomplish? Here you see one of the product team members, she’s now sharing that persona that her and her buddy created with the rest of the team. Again, a lot of this is about having a conversation to make sure everyone has the same information you can imagine here that her teammates are challenging some of the points or they’re adding to it. They’re making changes. So you can see that in one of those in the background, she scribbles and edits on these sheets and that is a sign of a really good conversation.

All right? So once we’ve dug into who we’re building it for now, kind of that next thing is to think about, okay, what is it that we’re building? Or another way to say that is I want to be able to visualize our product story. So in this case, we use a tool called story mapping in order to visualize the product story. A good story mapping session started out like this with a blank sheet of paper and some brand new pads of post-its and that’s exciting. Then from here, what we did is they started out by selecting one of their personas. In this case, it happened to be a youth and then one of their personas goals. When we outlined our personas, we specified the goals that they have. So this person would like to find a bed at a shelter.
Now we’re going to ask ourselves, okay, what are some of the high level activities we would have to complete to accomplish that goal? So she didn’t have to ask for help, she didn’t have to contact a shelter. So on and so forth. And then within each of those high level activities will ask, okay, what are some steps that they would have to take in order to accomplish that activity? Sometimes there might be more than one way to do the same thing we see here. Ask for help. She might ask a family member, she might ask a social worker, she might use google, so those all accomplish the same thing, but there are different variations. So as we start to lay this out, what you’re going to see on the story map is experiences unfolding from left to right or kind of across on the slide here.
And then variations of that experience of being stacked up and down. And we put the most common variation on top and the least common variation on the bottom. So as this plays out, across that sheet, you’re going to see the entire product story, that experience that she has playing out across that sheet. Once this goal is accomplished, we can go on to add other goals and also account for other personas and other goals that they have going across. So in the end, your story map serves as a tool for both visualizing and retelling the product story. And that’s pretty awesome. Now, when we did the story mapping with this team, you remember us as a 2.0 release. So they already had a lot of this application in place, and we kind of hit a little snag here in our discovery session with the story mapping because they’re getting a little frustrated like, hey, why are we doing this because we already know what the behavior of the application is, but at the same time we were looking to kind of fix some core usability issues that were, that were in the workflows and then to enhance the workforce so it could support a statewide rollout.

And it was interesting. We were kind of late in the day and I was facilitating the session, I can tell, you know, folks who are just getting a little frustrated with the flow of it. And a lot of these things kept coming up like, well, what about this and what about this and learn about this. So we just stopped the story mapping kind of in the middle. And we just started to brainstorm some of those. What we did is I had them take everything that they could think of in the present application. The things they were hearing, complaints about. The things that they knew kind of sucked and when we just started to write them out, so what you’re going to see here was that brainstorm and everybody on the product team that to add the things they wanted and then we kind of clustered things that were the same and the groups so that there weren’t a lot of duplicates.

Then what we did is each person on the product team, that one orange sticky was, hey, you know what, if we could only change one thing, this has got to be the thing. Okay. So they brainstormed all those things and they were kind of spread out over some different things. But there were also a lot of these stickies that were very similar in nature too, we found that there were certain groups that were around the search experience. And there were certain groups that were kind of around location services, bugs, small features, cumbersome workflow. So we started to clump those things together. What ended up happening then is it was kind of pretty cool. Y’all were, there were these clusters where we wanted to fix bugs and workflow, and there was this new stuff where we wanted to do the statewide rollout and there was actually a fairly substantial overlap between those two things and we found them in these three areas, the need for geo location, the core workflow of how to search for information and how to access that information and then the ability to receive a notification if a service became available that wasn’t previously available.

So, because that sat here in the sweet spot, we took all those things and we said, you know what, we’re going to make those the priority. We went from there and we went about kind of bucketing things and we bucketed together both new stuff and enhancements and then we ordered those buckets. And what ended up happening is we created a three phased roadmap just like you see here. And the really cool thing about that was like the whole product team, you could almost see the relief on their faces and in their body language because now they knew that this stuff that they were going to be held accountable for was also taken into account in the roadmap because sometimes we really only focus on new stuff and we ended up carrying this crud along with us release after release month after month and you know, it’s stressful for us as product developers because we want to be able to make improvements that make our users happy. So coming out of this exercise, the team had this roadmap, was probably about 12 to 18 months of work, but right from there, then again, we’re still on this journey of focusing and making product choices. So we said, you know what, now let’s just worry about phase one. We’re just going to focus on phase one. And that became what the rest of the conversation would revolve around.

Alright? So we’re going to zoom in on phase one. We went back to that story mapping. Then the next day, and we actually started over, we started over with a new persona and we started over with a new need and just within phase one, then we redid that story map, but same thing as before, experience playing out from left to right. Variations of that experience up and down. Okay. The story maps shows you the steps that the user will take, but it doesn’t necessarily give you a picture of the experience the user’s going to have. So what we did next was we did a design studio activity with the group and there was a user experience person in the group, and the other people were a little uncomfortable because they’re like, hey, I’m going to use your experience versus you. Maybe we design stuff, but that’s something that’s a stress about, the goal of the design studio isn’t to come up with the perfect answer.

It’s just to brainstorm a lot of different ideas about what the experience could look like together. So we challenged each person on the product team to either work independently or to work in pairs to draw what the experience in the mobile app would be that would match with the steps in the story map. So here you can see they’ve already done that and they put their pictures up on the wall. And what the team’s doing now is they’re voting with the pink flags on different elements of that experience that they thought were cool. They’re not saying, hey, this, you know, like Sue’s experiences really awesome and Samir stinks. They’re saying, I really liked this component, that Samir design here, and I think that’s something we could use. So what you start to see them was, all of these different product ideas were put up together in the team, called out different elements of the experiences that they liked.

And they talked through a lot of this in, you see a letter of repeating elements as well. When you lay it out like this. So then from there we challenged the user experience person to take them as best as she could to take those ideas into, blend them together into a single picture. And so this is what came out from that was a six screen mobile app experience that matched back to that story map that they had created that was integrating as many as possible. Those cool ideas that came out of that design studio. Alright, so now what this team has is they have a story map that’s showing the steps of the experience and they have a picture, a low fidelity picture of what that experience will look like. So really those two things together, pair to give us an awesome visualization of what our product story is.

But we’ve got a whole product story. We still kind of need to answer a couple more questions. One of those being like, Hey, where do we want to start? Because there’s still a lot of work here. Where should we start? What should we build first? What should we learn first? So then we’re to answer that question. We’re going to use a practice now called customer journeys. And you can think of journeys is nothing more than just a path through a portion of this experience. I always, whenever, when I first saw this journey thing, it reminded me of back when I was a kid, I used to read these, choose your own adventure books and basically it’s like a kids book, but you’re reading along in a story and then all of a sudden the story stops and it’ll give you a choice. And it’d be like, Hey, you know, if you want the prince to slay the dragon and go to page 32, but if you want the prince to get eaten by the Dragon, go to page 56.
So, as you’re reading along in this book, you’re making all these different choices. So like, Myriam and I, we could read the exact same book and have a really, really different experience. software is a lot like that too. Because as you interact with a product, you’re going to make different choices. There’s all these different variations. And as Myriam and I interact with the same software product, we may have a very different experience in that too. The other really interesting thing about journeys is there a path across an experience, they’re not a vertical slice of an experience. So I want to show you an example here. Here’s a hunk of that same story mapping. Remember we said one of those things on that first roadmap was to, for a youth to be able to set notifications. So you can imagine if I was a youth in Minneapolis and I was looking for somewhere to sleep tonight, I might look and see that all the beds at the bridge for youth are taken. But I could set a notification that’s like, Hey, if somebody cancels, alert me if a bed becomes available so that I can come now. And that’s what this hunk was in here. You see two journeys, there’s a red journey. That’s this path that you see outlined by the stickers and the marker and read. What was that about? Was about, was about text notification. Then the black journey is about email notification.

So, what the team decided here was the text notification was probably the more important journey, but they also made it a very lightweight journey. They said we’re just going to do the minimum steps necessary to support a user saying yes, I want to get a text notification and to be able to receive it. Then with the email or the black journey, they said, okay, yes, we’ll support email in the scenario, but then we’ll collect a little more information upfront too that might make it a little better in terms of the information that will give back to them. And the notification. The interesting thing about this is that their user research revealed that actually something like 95 percent of their target users don’t even have email. So getting this text capability out in the hands of their customers quickly was a very, very significant thing getting the email, not so significant.

Another thing. This is another place where journeys really help you out because this red line is a path through an experience, it has value and it could be released independently of, you know, some of the other pieces of this large area set notification. Oftentimes we have been conditioned to think in epics or an epic. Typically we’re a whole thing like set notification versus a path across. If we had to do this epic set notification and we couldn’t deliver it until that was done, we’d have to do this card before we could even deliver that red journey. So, the journey is kind of cool because it gives us opportunities to release something of value sooner. And in the case of the app for the bridge for youth, that means an opportunity to really, really help people sooner. All right, here you can see they’ve identified a bunch of different journeys on this map and they’d given these journeys names just like we name a story, starting with a verb and describing what the action is that takes place from there.

Then I challenged the team to order the journeys that identified something like 10 different journeys on the story map and we said, hey, let’s order those from one to 10 in the order that we believe we should do that. And as they were ordering them, one of them to take a number of different things into account. Of course you want to take into account what’s most valuable to the user, but we also want to take into account some other things. What might be the most complex to build, you know, there could potentially like blow up in our face or your end up being really, really hard. What might be the place where we want to learn first? Maybe we’re not sure if the paradigm that we’re using or the design that we’re implementing would work well for our users. Maybe we want to test something early on. So we might want to sequence the journey a little higher so that we have the opportunity to learn. That’s what I take into account. What’s the most efficient order to build these things. And sometimes the team can just move faster and be more effective constructing the software if they work in a different order. So we’re balancing all of these different things is we ordered the journeys.

So after coming out of this exercise with the team, ended up with was an ordered list of their 10 journeys, in each of those journeys had within it different steps or different stories that we saw on our story map here, you’re starting to see this ordered list of both journeys and stories for the Astute among you you’ve already come to the conclusion that this is starting to look an awful lot like a product backlog. We could imagine this structure sitting in Jira with our epics and our stories. Also, if you’re looking to construct a roadmap, maybe you’re more of a PowerPoint kind of person, that a Jira kind of person a you got to do is turn this sideways
and you have yourself, your product roadmap over some increment of time. The cool thing about these journeys is these are all independent testable valuable things. So after each one is completed, you would have the choice, hey, is this something that there’s enough value in it that we could release? And you could go ahead, put that out into production, learned from it and provide value to your users. All right, so now that we have are ordered this to journeys and we have a general idea of what our stories are, hey, we can go ahead and do some story authoring too. We’re almost there, made it all the way to the stories, my friends. I’m here. You can see that the team selected that first journey and they actually copied the steps that were on the story map. Now they’re going about authoring those stories. And again, we’re doing this in a really low fidelity way, answering three basic questions to describe the stories where we building this for, what are we building?

Why are we building it? You can think of these are really the three basic questions that, that classic as a template forces us to answer. And then the team is also creating acceptance tests or acceptance criteria. We want to use acceptance tests. Describe the behavior that we would like in that story, but to do that in test language versus in requirements language. So what I mean by that is, something that’s been written in test language can be validated where we can ask the question, did that happen to true or false pass or fail? It could even, you know, in the best of scenarios become an automated test. Back in requirements language. we used to write requirements that says something like, Hey, you know, the system shall be performant. Well, what the heck does that mean? I’m in test language. It would say something like the App should be able to identify my location in less than a 10th of a second.

That’s a true or false, something that we could write an automated test to. Alright? So in the end here you can see the output of the teams discovery session. Okay? Kind of off screen they had, they had done collaborative framing. They also had done those personas so they know who here you see the story map, which is the what, what experience do we want the users to have? These are the activities, the steps, and accomplishing their goal. This is what that what looks like the user experience from there. Then we selected journeys or paths through that experience. They ordered those journeys seat and see the numbers here. And then once those journeys got ordered, took that first journey and we said, hey, let’s start writing some stories for this. So you can see here how we got from that idea. Hey, let’s go statewide. Hey, let’s fix some usability. I’m all the way down to that first set of stories that they would feed into a sprint.
Right? So as you go back to the real world and you look to apply some of these practices and maybe have one of these discovery sessions with your team, here’s some keys to keys to success in that. Um, first of all, don’t let anyone pressure you into like jumping right away to just write all the stories he used to get. Told that all the time, you know, just go read the stories. I’m like, ah, I don’t even know what this thing is. It never seemed to end well. It always ended up with writing the stories like three different times. I’m one of the cool things about this discovery is you’re able to maintain that product focus and the vision throughout your learning more about your users. You’re learning more about your market and you don’t lose that as you go down into the journey level and into the story level.

You still have that big picture of that map and that frame that you can reference later. This also really helps you to make product choices and then to enable focus and you can see in the story with the bridge for youth how they started with something that was broad and complex and in some ways a little ambiguous and they got to something that was very clear and actionable in a very short period of time. Did they get it 100 percent right? Nope. Just some things changed later. Yep. But they were able to start and they were able to start quickly and in the end it saves you a lot of money and it helps you to learn faster so you make better choices on behalf of your users. We use a lot of practices that helps us to visualize the experience versus documenting the requirements.

I mean you saw a lot of pictures, drawings, a bar, napkin sketches, and maybe that seems too low fidelity or too trivial to you, but I actually prefer that over documentation. A lot of people are scared off by walls of texts and you know, that old adage that a picture says a thousand words, it’s never been truer than in software development. This also is a great opportunity to bring the product team to gather. Everyone has the same common understanding. Everyone gets to be a part of it. Everyone has buy in the beginning versus the product team handing a set of requirements and saying, hey, go build that. And last but not least. I mean, when you’re doing this with your teams, don’t forget to have fun. This is a really fun thing to do, an activity to do. And I mean, I think it’s like this type of design is the core of the cool stuff that we get to do as product developers. So don’t miss that in the moment. All right, so that brings us to the conclusion of this Webinar.

So, one of the questions was kind of a clarification you mentioned Mike was asking, you mentioned a low fidelity. What exactly were you referring to when you mentioned low fidelity? Take for example, something like a UI mock up. You saw a lot of things in this presentation that know almost like scribbles Kindergarteners might do. A lot of times the user experience team will provide us a high fidelity mock up and I would say I would describe high fidelity as something that’s picture perfect, that has a pixel perfect that has, everything’s exactly in the right place, exactly the right colors. The line in depth is perfect. You know, all those things well, there’s a lot of time and expense that goes to creating a high fidelity artifact. What you saw in this presentation are low fidelity artifacts. It’s the opposite extreme of just hitting an idea out on paper. It’s not pretty, but it’s something that we can have a conversation about. Low Fidelity also comes quickly and cheaply, but that’s not even the most important reason.
The most important reason is low fidelity because there’s less effort. We as human beings become less attached to that artifact and we’re more willing to change it when we learn, we can imagine if we’d spent weeks creating high fidelity UX mock ups with the expectation that they should be perfect when we deliver that thing, we’re probably not going to want to change it, but if we spend five minutes sketching something on a scratch sheet of paper and somebody says, yeah, but what if we did it this way? We’re like, oh, okay, let’s try that. So that’s always encouraged the use of low fidelity artifacts.

Myriam: Okay, great. Thank you. So then we have a couple of questions that relate to, I guess a timing and length of time that this process might take. So Julie was asking how long was the resource given to build the merge product story? And then Ed was asking, how long would this, this entire process of breaking down the stories, etc. take in general, you know, based on the size of the project.
Anne Yeah. So in This specific case, this team spent, and it was about five people, they spent two days in this facilitated session. The length of the sessions tends to vary a little bit depending on how big the thing is you’re trying to work with. I’ve done them in as little as about two to four hours and as much as about three days because it’s much more than three days. It’s probably to honk and big right away and we should probably have a conversation about like, hey, where do we really want to start with this? But that’s okay and do that in this session. And then when it comes to the second question about, okay, how long did it really take to get to all the stories? I know I’m paraphrasing that a little bit. That’s not exactly what you asked. But one thing I do want to point out is we didn’t exactly offer all the stories.

We had that big picture of the story map and then we started off their stories for the first journey. You definitely don’t want to create all of the stories for something like this, you know, let’s figure this was three months of effort at once because things are going to change, so you want to create those a journey at a time, and really only look to be a sprint or so ahead of your team in terms of offering those stories and if the authoring of stories is something that’s interesting to you, that discovery and that type of, you know, timing of when, when that should be done is going to be one of the big topics in our next webinar.

Myriam: Thank you. And now we have a question about a clarification. So Melanie a clarification, you know, other presenters talk about, the product topics and you know, reading the literature. And one thing that she’s confused about is what is the difference? And if you really can define it very clearly between a product manager and a product owner.

Anne: Oh sure. Yeah. That’s a question. And it tends to vary a little bit depending on where you go. When I use the two terms, I mean them to be exactly the same thing, and, and I mean them to be that person or group of people in the product team space that answered the questions, what are we building, why are we building it, who are we building it for and in what order should we build it? And to me, that’s what I mean by that role. Product manager is a term that we’ve had around for a really, really long time. I’m product owner was a term that was first introduced into Scrum. I kind of liked the term product owner a little better than product manager because it really is about taking ownership or taking responsibility for your whole product. But as I’ve used the term, I mean them to be the same thing. I go a lot of places in the industry though where product owner tends to be the person that’s working closer to the team. And a product manager might be a person that’s more strategic and more aligned with the business. But that isn’t necessarily always the case.
Myriam: And then we have a question from Adam. How do you handle technical stories or backend system requirement planning sessions?
Anne: Yeah, great question. And I’m just going to back up and show you something. So one of the things is we look at our story maps. We want to think about both steps that the user would take and also steps the system will take you see on the story map, some of these stories are turned and looked like a diamond. Those are actually steps that the system will take. You can imagine like in this scenario, they choose the shelter all of sudden and the system is going to bring up a map that shows them where their location is relative to that shelter. That’s like, sometimes we might call that a backend story or something like that, but it’s very much still work. So the first thing that we do to kind of think of those technical stories is to think in terms of system steps to that will help you to express back in work in smaller, more independent testable things when it comes truly to technical debt or bug fixing or that type of thing.
Bugs I usually wouldn’t put as a story but when it comes to technical debt, yes, I would create stories around that. A lot of times, like if you were working on a journey and we were working on that set notification, if we knew there was some sort of refactoring opportunities or technical debt in that area, might want to queue up some of those stories as part of that work because we’re in there anyway. So that’s how I would account for those types of things. But I do believe they should be in the backlog and I do believe to the greatest extent possible that we should express those things in terms of value delivered. And yes, system actions count too, and we definitely want to capture those things.

Myriam: Okay. Thank you. Ryan asks, can you talk more the difference between the steps in the story map and then the actual user stories you write at the end of the product discovery process?

Anne: Yeah, that’s a great question. They would map where the steps would become the stories, but in reality often find that sometimes the steps might be a little too big from that initial discovery session. And when you go back and you look at that journey, you might be like, ooh, this here actually needs to be split into three different system actions, but loosely to begin with, I would equate the yellow stickies to the stories. Then as you’re going journey by journey in your offering, the details as you start to suss out those details, you might find yourself needing to split those stories into smaller pieces.

Anne: And then we have a question from Shamita and I think maybe it’s opening a bit of a Pandora’s box, but I think it would be an interesting thing to get your perspective in terms of estimating the sizes for these stories. she’s asking, story points or hours?
Myriam: Oh, that’s a great question. You know, for stories I think I’m going to punt, but because we’ve been talking about journeys or paths, you know, that’s typically something we’re going to size too and at this stage during early discovery, I would not want to use points or hours or days on a journey. I’d want to use something a little small or a little higher level, like a potentially a tee shirt sizing, small, medium, large, that type of thing. When we get to the story level, you know what, there’s a lot of different schools of thoughts on pointing and I don’t have a passionate opinion about story points versus days or hours. What I do have a passionate opinion about is we need to get stories roughly to a size where they can get through the sprint. Typically I find that to be about half to a third of the sprint length.

But you can see that for yourself with your own team, if you watch sprint after sprint, after sprint, you’re going to start to see, hey, there’s a certain size of story that always carries over. Maybe it’s an eight, maybe it’s 10, maybe it’s an elephant or whatever, but that one always starts to carry over if it’s carrying over. sprint after sprint is too darn big stuff. Don’t write stories that are that size anymore. If you follow that philosophy are pretty soon going and get to a point where all of your stories are about the same size and once you get to that point, estimating and all that junk is going to become a lot less interesting. You’re going to transition from as a team asking the question, how big is this too? Just getting to the point of is it too big or isn’t it?
Myriam: Okay. Thank you. We have another question from Julie kind of relating to what type of a role would participate in this exercise? Would you encourage to have a CSM or a member of the dev team engaged in this type of exercise if they have availability?
Anne: Yes, absolutely. In fact, I believe that to be critical, we at a minimum, if it’s feasible, I mean if it’s a 100 people working on a product, we don’t want everyone, but if it’s a small product team, I would advocate to have everyone there. If it’s a larger initiative, you’re going to have representatives from different teams, but as an minimum we need people in the room that can answer the question what’s valuable, what’s usable and what’s feasible and what’s feasible is absolutely going to need to be somebody that from the dev team that understands the codebase and understands the technology.

Myriam: Alright. Thank you. And then we had a question from Jodi and I have to say that I have a personal interest in this question and you’ll understand why as put it out. Have any of your clients asked you to apply this framework and methodology to other functions of the organization such as marketing?

Anne: Yes, absolutely. We’ve done this for a lot of things. How about marketing, Myriam?
Myriam: Yes. We had the privilege of having Anne work us through a workshop like this for an initiative that we were taking in the marketing department, and I can tell you that it was an extremely interesting experience and a very valuable one that allowed, and I think she mentioned that in her presentation, but it really allowed us to move forward and to start doing the important things.
Anne: We’ve applied these principles across all types of product development, food development, libraries, a scientific research, a hardware manufacturing. So yes, uh, a lot of these practices can be applied widely on the software world and beyond.
Myriam: And then we have probably our last question for the day from Tim. Do we have to use this way to break down the stories and it’s still valuable if we’re not technically working in an agile environment?

Anne: You don’t have to do anything to him. I think all of these things when it comes to process pieces is about selecting the things that would have the right value for your team. That being said, I think a lot of these practices would be very valuable even if you’re working more in a waterfall environment or working on a longer cycle time because those elements of being able to focus and being able to start and to begin learning by building working software are going to have a lot of value. Also getting to know your user, understanding the experience, having that big picture in a visual manner. I believe that to be uniformly beneficial regardless of your process methodology as well.

Myriam: I’m going to be the last question, but I do have one more question here because I think it’s kind of called to something that maybe we didn’t address specifically is how do you reach a consensus, when there’s ideas and we’re not sure which way to go. What would be some manners that we could resolve conflict?

Anne: Yeah, that’s a really good question. I’ve seen more times than not when the team comes together and is focused on this conversation, the consensus usually falls out. But sometimes I use some voting tools. Sometimes we’ll time box a passionate discussion, something like that, but really in, in this current goes back to the question about like the low fidelity to a lot of times just being able to visualize these things and to quickly see and have that same understanding, some of that conflict and that disagreement that we had before it starts to melt away because we’re all starting to come from that same direction. I guess another thing to this point is a lot of our clients, sometimes if the situation is contentious, they might choose to have that third party come in and facilitate the session. Somebody who truly is a neutral, and that can be helpful in enabling a team to work through that and for everyone on the team to be able to represent their own position in viewpoint, while the activity is still moving forward.

Myriam: Okay. Thank you so much. And I want to thank you very much for again sharing some great content today surrounding the complex task of creating awesome stories for a backlog. And, we also want to say how much we appreciate you taking the time to join us today on this Thursday and we trust that you have all found this session of value. As a reminder, we will be sending out the recording of this presentation as well as the slide and we really hope to see you for part three on October 23rd on managing backlogs and also on many of our other webinars that we’ll be putting out in the future. We appreciate your time and enjoy the rest of your day. Thank you everyone.