Idea to Product in Custom Software Development
Geoff: Hello. The title of this presentation is Idea to Product, but really what I’m here to talk to you about is story mapping. And actually let me just see how many people know what story mapping is. How many people have done story mapping before? Oh wow, a few.
Geoff: Okay, cool. So instead of like taking from a bunch of text, I actually put up something I did for a client. We did a story map and at the highest level, a story map is a visual time secrets representation of things that get done in the application development process. Actually in some cases it can be outside of an application. So you could do a story about for making a peanut butter and jelly sandwich. You know, the traditional, I almost did that example, but it’s so cliche. I decided not to, but in this case we were trying to figure things out for a prospect that had an idea for an application, though they didn’t know what they really wanted.
Geoff: And that’s ultimately when I use story mapping, I say let’s sit down and talk about who the users are and how you envision them using the product. Because if someone really has no idea what they want or they’re unclear, this is a really great way to tease it out and represent it overall.
Geoff: So I was working with a customer and they had a lot of ideas of what they wanted. But to turn that into a roadmap or any actual story level idea that we can estimate, we had to do a story map. We did this multiple times across multiple products and by the time we were done, we had a lot of clarity about what we wanted to do in the MVP. And it does actually in this example that I’ve put up here, we’ve got MVP release lines. So for me, some of the most valuable parts of story mapping are talking about hard decisions like MVP release points. And story mapping is hard because you can’t always have everything in that first MVP, but everyone always wants everything!
Geoff: So there are some hard decisions that have to be made. You can start talking about that during story mapping, visualizing it as you’re doing a story map. I love this way more than the traditional requirements gathering, quite honestly. You get the right people in a room and hopefully it’s your business, your technical, your developers, if you can. That’s a bit hard in our industry because it is billable time. But if you get a lot of people in a room to start talking about who your users are, what are they trying to do, and what you’re thinking, instead of like it’s a blue app with a button, and you’re actually getting down to what should this application do and it will be very valuable. Another great thing that story mapping does is it creates knowledge transfer. So we’d go through this story mapping process and by the end everyone that is sitting in a room, kind of understands what we’re trying to achieve with this app.
Geoff: You have a common language, you have personas, you have things like that. Departments gap documents because of the way they’re gathered traditionally in separate rooms and they’re not used for like six months. The other nice thing story mapping does is it captures stories in time sequence. So left to right per persona is initial to later on to the use case. And that’s not always completely true if someone could commit in their profile, the beginning of the end. But traditionally you have to login and you have to register. You want to do things like that. You want to do initial setup and you’re going to do that in time sequence per user. And honestly, I find this to be extremely fun. For some people it can be a bit chaotic and hectic. Partly because I really encourage everyone sitting in the room to participate even if they don’t really understand it yet.
Geoff: Everyone has the opportunity. There’s stickies sitting there, we collaborate. You could have, if you have enough people, I’ve seen groups of people standing there having a discussion. We’ll log in and how do we want to do log in and what kind of reports we want to run. And there’s different people off in different areas and they’re talking and they’re collaborating. And then we come back and we talk about that. Another thing that don’t have up on the bullet points is it’s really hard to do story mapping remote. The best story mapping is done in person. That can be a challenge. It is possible to do remote story mapping, especially with some of the newest software they have. It does real time, but it’s not the best usually requires a more a linear focused conversation than kind of free form, ad hoc. One thing that I like to do is I sit there and I’ll traditionally write down as I hear things- someone mentions s a feature, I’m going to put it up on the board.
Geoff: And that’s one thing that I talk about a lot and I’ll definitely preface with the business people just cause we put something up here doesn’t mean we’re building. This is not commitment. This is ideation, this is brainstorming. And we want to think through an ideate through what do we want this application to do over time. Um, the other thing that I allowed to do, and I say with permission, cause traditionally you want to check with the person who wrote it, but if you pick a card that’s vague or you think you’ll have a better idea of way to write a card or maybe a card represents three features or three stories instead of one, like, Hey, I think this is two stories, I want to do this and this, what do you think? That person will get up, they’ll hold on to one card, they’ll rewrite it as two and put it back up.
Geoff: So not only are you iterating on your ideas, you’re iterating on other people’s ideas. So the story grows, emerges, and lives over the time that you’re doing it. You can include tests that are done actually physically as well, if that helps you visualize and represent everything that needs to be done. Keep that in mind. So the colors I could have told you have talked about already and I put a note down at the bottom, I don’t really care what colors you used. Just each level needs to be distinct color and as you do that story map, they need to be unique across that area.
Geoff: So the persona, and we’ll talk about what a persona is. If you don’t know that the activity is a category, then you have a story. Again, not in true story format, I’ll talk about how that, when that comes, that comes later. But basically just a general task, a feature. Some people call it a feature as well. And then one thing that I do because uh, developers will stop talking about it and I don’t want to lose the knowledge as I do what’s called a system story represented by a diamond and I’ve got a couple up there and that usually emerges from like, well these are just this. Oh yeah, we totally have to remember the system needs to do this thing as a result. Great, let’s capture that. Let’s put it up there as a system story. That means the system is doing something usually based on a user input or doing something but not always. So it could be scheduled. That could be time based, it can be anything like that. And it is, it is a story. So as a user, I would have received report every week. The system used to do that every week.
Geoff: So a persona. How many people here have seen or worked with personas before? Okay, cool. So more of you. So this is um, depending on the customers, sometimes customers have their own personas, which is awesome that you can just use them and they have names. Sometimes you’re starting from scratch. This type of persona is usually only provided if the customer has it already. Or if you’re going do a long project and you want to build it up over time when you first sit down, traditionally we’ll come up with personas and what I do, cause it’s real fast as I say, like for example, Andy, Andy, the app user, tell me about Andy. Well Andy is probably 25 to 40. Uh, uses their mobile phone constantly, pretty tech literate. And then from that point forward you can think about Andy as you’re designing it. What would Andy like, what would any dislike…
Geoff: Again, in a really good story mapping session, you could actually hear people arguing like, no, Andy wouldn’t want to do that. No, that’s not how anyone would want to use that application. They would totally be pissed off if it did that. And that’s a good sign that you’re emerging and seeking about putting yourself into that users role, which is really important. So again, you don’t have to do this, but a persona is required and usually you pick the business, the subject matter expert, whoever and say, tell me a bit about who you think this person is. In some cases we’re doing Greenfield. Were you thinking about a theoretical user theoretical role? It may not be known even like this is what I’m targeting this persona. In this case. That’s exactly what it was. We think Andy will want to do this. This is how they want to use the application. The couple of lessons that can emerge as the businessman that think about this, they even think about this for two years and you make a couple of statements and they’re like, Oh man, we never really thought about that. Yeah, I never thought that that’d be completely inconvenient to do it that way or whatever it is. So we could start showing value as part of that process as well.
Geoff: Another thing that this does and I mentioned already is you could start talking about, as I said, releases as well as a walking skeleton. So if you’ve never heard about a walking skeleton, it’s an agile term. It’s basically the first set of features that start to represent the app. So from a design perspective, it could be the, you know, the first five or six things you designed that give you a good sense of what the application will look like. It can also be the first five or six stories that you write. So you could start to demo what the application looks like. So building out the walking skeleton is a great way. If you’re looking to get speed, like we want to know what this is going to look like and we want to quickly, we can’t build every feature, we’ll start to give them ideas.
Geoff: So I represented the walking skeleton on this one, black dots. So these ones with black dots, those are the ones that I’m going to have to design to actually prototype first. And then those are the stories we’re gonna load up first. And theoretically it is complete working end to end code like a normal story. So that’s one of the things that we have struggled with is if it takes long enough, you start to question the value of the project. What are we doing, why are we here?
Geoff: Customer can really see like cool, they’ve already built out a couple things. I can really see the vision of it. I like the design. I can see where we’re going, this is great, right? I may not always be possible. Some customers are very pragmatic and picky in the order that they want to go in. But just to be clear, just because we’re going this doesn’t mean we have to develop in that order either. And of course that should always be discussed between business and development. What order do we go inand why? The other thing you had to start talking about traditionally is MVP beliefs. So I did a couple of stickers here below that blue line. Those are things we’ve agreed. We don’t need them till later. Um, and a couple other things is as you look at stories, traditionally you go verdict in a story that the same task, just different versions of it.
Geoff: So in this case we’re signing up, we’re setting the username password or we’re doing Facebook, SSO. Those are basically the same tasks, but they’ll represent different stories in the backlog. And then why Google later and below this line, sometimes what I do with customers is just what do you need to have a product? What can come come later in some cases if you want to play multiple releases, I’ve done this as well. You can have multiple. . So you can start to plan out your releases as well if you want to. So it can be very helpful. And as I said, very helpful in guiding the really hard discussion about what I usually say when I start this, especially if a customer that are not familiar with agile or those principles. Like if we design an MVP and it doesn’t hurt, like how a little features it has, we probably did wrong.
Geoff: We probably are trying to build too much. Do you really need this feature? Do you have a product without it? And that will drive people to be like, no. I mean Google is nice, but no, you’re right. We don’t need it in the first release. And in some cases people will be very clear like, Nope, we don’t have that. We don’t have a product. Helps drive that discussion. If you’ve been in one of my sessions or if you get to be in one of my sessions, I’m really pushy about a lot of things and this is one of them. You got to call people out. Like, are you sure, you absolutely sure , or are you guessing? Do you know, do we need to go test users? Do we need to go do some interviews?
Geoff: The other thing that you can also plan, so we talked about releases, but also if you’re doing a CICD you could talk about phases. And in some cases the MVP might be the first release, but after that we’re going continuous deployment, continuous release. So now we’re just breaking into phases, chunks of activities that are similar, you know, iteration on expanding logging capabilities or whatever it might be. It represents a phase or Epic or something like that. So don’t think that you just have to have this in a pure, quarterly release annual release type environment. You can use it for whatever you like.
Spire Team Member: Would you do story mapping before? Would you do it if someone hasn’t done the user interviews that you mentioned like, or, we should we always do user interviews or does it just depend?
Geoff: It just depends. Honestly, a story mapping can bring on areas where everyone’s like, wow, I’d really love to talk to some people about this before we build a single feature and you may have already done user interviews. I mean sometimes you need that iterative process to really figure out what you need. We don’t always have that time. But. I mean, usually user interviews in the beginning to me are not sure they have a market.
Spire Team Member: Yeah.
Geoff: I’m not sure if I want to build this. I’m not sure if it’s worth the time or money. You do enough of that to vet. Let’s say like we’re thinking of doing this, like here’s our idea. What do you think? Would you be willing to pay for it? If the answer is yes, then you can go into more ideation, story mapping. And theoretically what you could do is user interviews. Yep, I think we have a market, let’s do story mapping now let’s design a walking skeleton and I’ll go back and do more interviews and say, this is what we’re thinking of building. What do you think? And if people are like, yeah, I’d pay for that. Keep going. People be like, wow, you missed the mark. They come back and do a different story mapping.
Spire Team Member: Cool.
Geoff: Also, there’s a couple of other things I’ll use in this, which are a bit cheaty, but one of the options is, Hey, we could just put a button and when they click it, we capture that and say, cool, this is coming soon.
Spire Team Member: Hmm.
Geoff: Thanks for letting us know you want it. Or things like that. Right. Depending on the customer, some people are really cool with the agile iterative concept. Some people really want to do everything over expensive time consuming. Completely unnecessary.
Geoff: I’ve seen people changing their mind. They’re like uh fine like you’ve talked me out of it like half an hour later cause they were thinking about it. Okay. So I’m going to pause there because part of what I actually wanted to do was story mapping. This is a really cool thing to understand in theory, but until you’ve done it, you don’t know it. So I actually brought up a use case. Like I said, this is a prospect. I felt safe using it because they didn’t end up building this app. Well let me stop here. Story mapping in general, what questions do people have before we begin?
Spire Team Member: I have two. I’ll start with one. It sounds like you’re representing the user in this process, how are you representing like the budget that you’re talking through, this feature costs so much money and that it’s going to give, you know, even a hundred thousand one of features, like you really like it, 10% of value. Do you ever work through those problems too?
Geoff: Sometimes. Usually it’s in terms of now or later. Wow. That feels like a really big feature. I won’t talk money, but like I’d really recommend you wait on that and we’ll talk about the outcome of story mapping and how it turns into a roadmap. That’s usually where money comes into the conversation because a lot of times I’m kind of using my gut to guide on MVP, people, time, and money. But eventually, sometimes I say well you can want that now or wait to get the roadmap then tell me if you still want it. But I try not to in the moment cause that can, to some degree, limit a conversation. It’s not a no, it’s just a now or later and later may never happen. Honestly. It’s fine. That’s cool. But you’re not saying no.
Spire Team Member: How do you know how granular to go? For instance. Is it enough to say login or do you discuss password strength or
Geoff: No, traditionally you don’t/ I’ve done some story maps where, um, and a good example may not be password strength, but like filtering or searching. So it’s like, what do we want to filter on? Sometimes I’ll delineate on like first-level simple filters and that’ll be in the MVP. And then we’ll add advanced filters later. And it can be as simple as basic filtering, advanced filtering or the fields are actually listed. So you’ll see filtering and then you’ll see a list of fields. And if it feels really important to capture something, like if it feels super important, I’d write on the note, you know, use industry standard eight to 16 character password requirements.
Becky: I think in this case the client was really focused on wanting a single sign on, which is fine. We talked about it.
Geoff:Yeah. But traditionally I don’t, and here’s the key. It does take away the waterfall business requirements, but you’re still talking about stuff that over time you’ll forget. So we do put it into a different format when we’re done. That makes it better as well as that may be an important decision if you’re going to start it soon. But otherwise you’re probably going to forget the decision you made to make a different move later. So again, if it’s something like a system test you really want, remember the system has to do that or you really want to remember that like this is, this has to meet HIPAA requirements, put that on the sticker itself, and then that can be put into the sticker. But traditionally, uh, you know, stories end up having to be one to 13 points. That’s where a developer or product person comes in handy. You say, wow, this is like a four week task with, we need to figure out how to break this apart. And just using your gut, if it feels like we’re arguing about something that’s gonna take half an hour, it’s probably too small. Ultimately we’re at that story level.
Spire Team Member: Can you ever be successful with two or more personas?
Geoff: So sometimes what I’ll do is usually the most common place where you’ll have two personas doing a lot of stories is you have a super user who has more features, but 80% of their features are the same. So maybe I have Andy, the app user and Sam, the super app user. I’m going to map out all of the common stuff first and then I’m going to map out the stuff that just Sam has. That’s the most common use case of two personas. Also, another place that happens a lot is the customer’s administrator and then our customer who has super admin capabilities, they tend to have a lot of the same capabilities to admin. And then our customer also has super admin, which is look at any of their customers internally in the application. But yeah, it does happen. There are some where it’s like anybody can use this app. Okay.
Spire Team Member: It makes me think of like Snapchat.
Geoff: Well, but in that case you probably do have personas. You just got to think about what makes them unique. I don’t use either of those because they’re not interesting to me. Right. But why are they interesting to someone who uses them? And who’s your core? Who’s your core user? Who are the ones that you really want to make happy, that are more likely to stay on the app and continue? Use the app? Or like me, I use Instagram every three months cause I forget I had it.
Spire Team Member: Yeah. I’m thinking like people who go in there and use it for just like purely communication or people go in there and like want to use all the filters.
Geoff: So you’ll it sometimes then that starts a great discussion you’ll have in story mapping about toggles. You can either have a experienced toggles. So a good example of that is day night shift. Like it’s this simple toggle, I want the net experience a day experience. So that may be the same user or you can actually have, I want to be a basic user, I want the basic experience or no, no. Give me the advanced experience and you could story map those out differently and have different stories and let the user choose which one they want potentially as well. You’ll usually start with the basic persona and then add the advanced later. But it just depends on what you talk about during the story mapping process. So, but yeah, I mean you absolutely can. It can be a very specific, like we have 10 people in the office who do this and they’re all the same type of BA or it’s like anyway, to have the plan.
Geoff: It may download it and use it. Yeah. So.
Spire Team Member: Does any of this process change for physical product?
Spire Team Member: Like a peanut butter and jelly sandwich or something.
Geoff: Not really. I mean, there are variations of what you can do. You can have crunchy peanut butter or creamy peanut butter, right? I mean, these are the examples. But not really, I mean, you could do a story map for almost anything. It’s just I’ve found it’s most helpful in software because physical things are easier to envision and use versus software, which can be hard to get your mind around. And as well, you have a lot more flexibility with software. I find it physical things. Okay. What other questions are there? Okay.
Spire Team Member: Do you think that people should have experience with walking skeletons if you’re hiring them.
Geoff: Not every company uses it. It’s a core agile tenant. People may or may not know it. Customers may or may not have patience or time for it either. So I don’t think so. Cause ultimately it’s just building stories in a specific order and doing design in a specific order. There’s nothing really special about other than the discipline of doing it. Yeah. Okay. Do people on the phone have the capability to ask questions if they want?
Becky: They usually Slack me. I don’t have any Slacks. Slack me if you have questions.
Geoff: I can only tell you from my experience. Sometimes you’re iterating on features that already existed, building well-known stuff. It’s not, it’s not a great use of time. Then if you could write a backlog of stories pretty easily and feel comfortable with them, you don’t need this. If you don’t know where to start, you need this. I’d probably guess it’s like 25 to 30%. It’s not widely adopted. I’ve introduced this to a lot of dev teams, from the last company as well. It was beneficial when we used it, but we didn’t always use it. We didn’t always need it.
Becky: We’ve been working on Remax for I don’t know, since January, and we’re doing it for the first time in a couple of weeks. Yeah. It’s at a point where we’re like, we’re not sure how this series of like payment features will work.
Geoff: Right. And that’s a good point. There are sometimes we’ll meet with prospects to say, hey, this first phase, we’ve done this a billion times. We don’t need to do anything special. When we get to phase two, you’re not sure what you want. We’re gonna do some story mapping. So even on the same project, they may not use it for the entire project. It is expensive. You traditionally get a lot of people. In my last company, I met flying people into one place, which wasn’t against the rules, but it was harder to to do so. So you kind of met that resistance.
Spire Team Member: Yeah, I thought that was interesting. It seems to me like traditional method of gathering requirements would be just as expensive, if not more expensive.
Geoff: and more useless quite honestly if you ask me really useless. If you’ve ever seen a good set of business requirements, they mean nothing. The user will be able to do this… Okay. Why? I don’t know. It doesn’t help me.
Geoff: What other questions? Yeah.
Spire Team Member: Have you ever been in a situation where it didn’t work? How did you get out of that situation?
Geoff: I’ve only had two really bad experiences and even then they weren’t deal killers. In my last company we were going to build out a document management system and we bought a company that had one, but we’re going to build a brand new version of it. So I decided let’s story map, but the person who owned the company we bought refused to participants. He just sat there and told people to carpenter.
Spire Team Member: And the only time it doesn’t work is when people are just obstinate to the process?
New Speaker: Yeah. The other time was when the other people, ah, so that’s not exactly story mapping. I had a developer refuse to do story pointing once, but that’s, we’ll talk about that kind of after. This process, like what comes later. It’s usually people don’t participate or you get developers who want to get into the weeds too fast.
Geoff: But yeah, if you have a facilitator who’s good like hold on, we’ll go way too far or no, you need to write that down. Like right. Then you’d be like, write that down and be insistent. Great. Write it down. And you could show through examples at the beginning like you like, Oh, okay. And then people kind of get the idea and they start doing it. You have to facilitate and it definitely does require someone who like a good meeting facilitator. It can go really don’t go fast if you don’t have that because you could spend half an hour debating like requirements on a feature and that’s completely useless. We don’t build it for six months who cares. It’s not valuable, but no, never had one that actually bombed.
Geoff: What other questions? So nothing on the phone. Okay. So, uh, I did want to do an example. I apologize to everyone on the phone. That’s going to be really hard to do. As I said, this doesn’t work well remote. But the use case in this scenario was a mobile application basically that someone would join a company, a stores report program where they download off the app store and they’d get rewarded for their purchases. So there’s, I’ll show you the output we had and all the stories that we came up with, but that’s what I put up here. So we had like, Andy was the main user and then we had Sam who was a super avid, they basically worked for the company that wanted this app. And for this, you think of everything. So for example, if the cashier takes cash, you’re going to redeem these awards.
Geoff: And that’s what we walked through. So reward for everything you buy every day. It’s not up on the story map, we can talk about it, but you add your credit cards, it’s going to be through Stripe. Like you add your credit cards, your debit cards, and then we comb through your transaction history and say, Oh, you bought something from this Starbucks and this Starbucks, we’re going to give you an offer.
Becky: If you go to Rooster Cat all the time, put that in your transaction data and then be like, Hey, here’s a dollar off Drip, so now you might try Drip because you’re doing to get a dollar off.
Geoff: Yeah, exactly. Um, so I put these up here, but honestly I just wanted to walk through the process and we could do variations. We can think of other users. We could do some of the examples. Like if you want, we can talk about a report filtering that could show you some examples of what that looks like, like how we would do that. Um, but I do want to do some actual live story mapping. So this is a real example. I thought it was good. Everyone could kind of understand the use case, like downloading an app, getting rewarded.
Spire Team Member: what was it called?
Geoff : Scalable. So let’s start here. Let’s just start with some basics. So for example, when you’re signing up for the app, so I had, I did authentication rights setting, your username, set your password, Facebook SSO, Google SSO, What else do you have to do when you sign up for an app?
Geoff: So here’s an interesting example of where I might want to capture something. So, so I might want to log for GDPR, right? That’s what you’re talking about, that, that’s probably why you mentioned it. Right? And that, and the other thing is it allows me to do is start talking about those concepts like, Oh, just so you know, starting next year we’re going to have to log all these in. Every time you revise it, we’re gonna have to capture that as well. But you can start introducing that complexity to a business user or the customer or whoever it is. Right? Cause that’s really annoying. So we need to log, so this is what I would do to your example.
Geoff: Each acceptance. What else? And the other thing is, you want to leave a little bit of room as you go through. Oh, that is one thing. So we have these awesome glass boards here, which is great for story mapping because you could write on them, you could do all this stuff. Like these are perfect a at some places I’ll get the, like the big sticky pad and we’ll just put up the equivalent of this on a bunch of sticky pads. The only nice thing about that is you can take them down and keep them. If you need to careful about, don’t roll them up, play a slap, you roll up the cards, fall off in the back. Right? You don’t want to do that. But it does allow you to capture it for later if you want them. Like I said, at the end of this also show what I do with the information. It doesn’t just end here cause that’s not valuable. Okay. So we are going to verify email,
Geoff: You’re trying to relatively do this in time sequence and another thing is sometimes I’m just going to trust them and leave it out of the MVP. I don’t really care. I might suggest against that one actually. That probably should be an MVP but or dual factor could be later.
Spire Team Member: Is that just because they’re not using it right now or something
Geoff: Or they just don’t care, right? They’re not, yeah, they might not be using emails for any marketing purposes. It’s an app where they kind of want to collect people who remember who they are but they don’t care that much. It’s very important that they understand they maintain anonymity, they have strong security, things like that because it does connect to credit card and debit card data, but not everyone says that. I will do a little different one here, so reporting is another one that we tend to iterate through a lot. The question comes up, do I put each report down as a story? Not necessarily. It depends on again, and this is where a lot of your guidance got comes in. Like simple like simple set of reports. Like you do basic report me and I’ll write it down and I’ll put it up there and that might produce two or three tickets stories or something like that. But it may not, it might be very simple based on what you talk to and what they want and they may not be able to filter anything like that in that first release.
Geoff: Okay. That’s where my long gone being an architect.
Spire Team Member: What about like, so they have a picture or something?
Spire Team Member: Or their location?
Spire Team Member: So how are we collecting data? Is it through the merchant transactions or the the user’s banking transactions.
Geoff: So it is through the user’s banking transactions. So they log into Stripe, they set the credit cards they want to use, and then we’re authorized to get the transaction.
Spire Team Member: out of their banking?
Geoff: Stripe provides it.
Spire Team Member: Wait but when do, how do I know I’ve logged into Stripe?
Geoff: You wouldn’t. So we use Stripe. You just know like, Oh look, I have bank of America, I’m going to click on that and log in and when you log in it says I authorize this app to access your transaction history. So then I see what somebody could use Stripe and have a much easier way of authenticating. or an apps right to access an account or something like that. But yeah, there’s actually a whole section we didn’t include in here. I’ll show you the final list, but there was one that was basically like that, add account manage accounts, all that kind of stuff was in this map as well.
Geoff: Another thing that might emerge is as you’re going through is you haven’t put splitting apart categories too or activities. Basically while this, sometimes things go this way and sometimes things go that way as well. So you could say like, you know, like you said login sometimes log in here. Login it’s almost never a story. It’s an activity, right? Cause you want forgot password. You want, you know, air incorrect with use a new password. You may want some other things that’s almost represented by multiple stories too. A and then so you know, let’s see, a client management list, Here’s an example of what we might do or we might do a little bit more granular requirements, but filter by name and size.
Geoff: So you’re starting to design requirements, but you’re not doing acceptance criteria.
You’re not doing a true story yet. Okay. Okay. Anybody want to try it? Everyone shy?
Yeah. So you didn’t try what you said.
Spire Team Member: What’s the real goal? Is it a total number of users.
Geoff: I will show you.
Spire Team Member: Okay.
Geoff: so the real goal traditionally what would happen is you’ll be going through story mapping and at some point you all look at each other and go, it feels like we’re good. Like we have a good MVP or we ran out of ideas or whatever it is. Um, one thing that I do like to do is if we have a little bit extra time as literally just start from the left and walk through all the stories again, cause even in that two or three, four hours, you might forget something like, wow, this is really poorly written. Let’s rewrite this card clearer.
Geoff: It’s like when you take notes in a day later, you’re like, what does that note mean? You want to try to be look, you at least get to the point where, uh, and to answer your question right,
Spire Team Member: actually that was a good answer, my My real question was, um, what is the client want, right? They just want as many signups as possible. Do they want as many offers as possible? Or do they want as many purchase offers as possible?
Geoff: Traditionally you are going to talk through that right in the beginning. It’s like a high level overview or something like that if we don’t have it already. Yeah. Some customers provided to us. It’s a written documentation. Everyone needs to review that before we start and understand it in some cases. it’s like what do you want? Right. Good point. Uh, so after story mapping, one of the most important things is to take pictures.
Geoff: I traditionally don’t reuse story maps. It’s pretty rare that I’m going to take an existing story map and put it back up on a wall and iterate on it. I might iterate out a story map related to it I may. So a lot of times, especially if I’m in the capability, I’ll keep the story map. In this case, if I’m doing it up here, I’m literally just gonna start from top to bottom, left to right, and I’m just going to stack the cards on top of each other. So you could recreate it if you needed to, but I haven’t found that to be super valuable. I’m going to take pictures. The other thing that I’m going to do, so this was the outcome. Come on. Thanks RingCentral. You’re so helpful. This is the outcome. Okay. of, that story map and as you can see, there was a lot more that we did. We put the original order in here. So if we wanted to reorder to do an MVP or roadmap or something like that, what was our walking skeleton? What were system tasks? If it’s an existing application, what may already work or not work. And you can also have an MVP call if you want to.
Geoff: So they had a really crappy existing applications, but the concept was build it brand new. It was Greenfield from that perspective. So this is what you end up with. So this is the first collateral that you’re going to use because now you’ve made it, you’ve made electric and you don’t want to start here. You don’t want to start in Excel, you don’t want to try starting in Sheets. Trust me, it just doesn’t work. This process is way better. So from a so in um, depending on the capabilities and who’s in the story mapping, a couple other things. You can start design prototyping, you can start coding. I’ve done these sessions where literally at the end of a two day story mapping session we did, and people may not be familiar with this but I like sized sizing effort, exercise where basically you just start with each sticker and you say bigger, smaller and you do that until all of the stickers are in columns by size.
Geoff: They say 1 point, 3 point, 5 point, 8 points. Great. We put them into JIRA, we start coding. So if you have a lot of stickers that is one way to quickly size cause everyone’s there. Everyone understands the effort. I’m not sure it’s as applicable here. Part is because we don’t always start at the same time as a team. We don’t always have all the people available when we do story mapping. But a lot of times at a minimum, I’d love to have the tech lead in the story mapping if possible. But definitely you can start design prototyping, especially if it’s a discovery and one of the outputs is design. So in this case there was no code as part of the discovery. It was designed protests but we could start doing design. And then, um, what I will do in a lot of cases is I’m actually gonna take the story map, um, and I’m going to produce a roadmap from it.
Geoff: So I’m gonna take everything that’s listed as an MVP, I’m going to produce an actual story as a user. I want to, so that, that’s the format I like it to end up in. If you can do
that in the beginning, because six months later, full story is understandable. So this is not necessarily as understandable, but if you could say as a user I want to set my username and password so I can log into the future. As a user, I want to filter on name and size so that I could find a customer that I want. I’m looking for. That transfers some of the knowledge out of the room into an electronic format that you can use later.
Geoff: Yeah. One more slide. I try not to do a lot of slides. Okay, good. That was it. Um, but yeah, I mean ultimately it does exactly like you said, you start with what are we trying to accomplish here? And you get down to a working set of stories if you did it right and if it’s done right by the end, everyone has a good idea of what’s going on. Of course you’re going to iterate on it, you’re going to change your mind, you’re gonna be like how didn’t We didn’t think of this or that’s two stories instead of one, not a big deal. But everyone’s really well aligned in a much quicker fashion than six months of requirements gathering.
Geoff: Okay. And the other nice thing is because you’re doing it real time, everyone on the team has a concept. If you can be there, has a concept of what you’re building. They have the big picture concepts, which is a lot of people are like, well how do you do that without wasting a ton of time. It feels like a ton of time. But like someone said, traditional requirements gathering is a huge waste of time because that’s six months of requirements and then the rest of the project trying to figure out what the hell the requirements say pretty much or making up new ones cause you have no idea. Okay. That’s it. That’s really all I had.
Spire Team Member 5: Where was the magic?
Geoff: The magic is when you have a customer who comes in and says, I have no idea what I want and they walk out and say you know what Geoff, I actually know what we’re building now.
Geoff: It really cool when you can do that.
Spire Team Member: How often do you get to do that at Spire?
Geoff: four or five times now. And like Becky said, some customers we’ll do it later who are just not clear. And some I do it as part of discovery.
Want more content about product development? View our recent article about IT and systems architecture.