I'm here with Bill Wake, 15-plus year veteran of AGILE and a major contributor and thought leader in the space. Thanks for joining me, Bill. >> Thanks, Alex. >> One of the things that you've done that had a big impact on how people think about narrative and the type of inputs we bring into the process is your invest acronym you created for user stories. Can you talk a little bit about how you got there, your thought process? >> Sure, I was doing a lot of coaching with groups and with different product owners at the time and seeing just similar struggles in what's the right kind of story and how should I be writing these and how do I put it together and so on. So I just sat down for an afternoon sometime and sort of writing out every attribute or adjective around the stories I could think of and just started grouping them. So independent and separate and unique or something might be in one cluster, and I would cluster them around. And then try to identify kind of what are the biggest clusters and the ones that matter the most. And I tried to find sort of a central word in each one that I could take the first letter of and make an acronym out of. So I remember shuffling things around and thinking vesting or vestige or something, and realizing invest might work and definitely was a more positive word than vestige. >> [LAUGH] And what have learned about the use of storage? I mean, if you had top five silver bullets or patterns you see over and over again with teams on things that make them more successful, what would some of those things be? >> Yeah, I think the biggest one I run into a lot now for whatever reason is I see teams that think about the mechanics of calling it a story, but the quote stories they have aren't really about users so much anymore. So sometimes, they're writing stories that are about the components of a system, so I'm, as the search API, I'm going to do something or as the database will do this, and it doesn't have much connection to the user. And so, I'm looking for, so one thing is to make sure that your stories are about things users really want and that they're not things about how we're building this system. And they're certainly not things about how we're running our process, so that's the second why I really see it's funny to me. As this team, we're going to have a stand up, so we can talk about this or something, it's like, no, that's no story. But people are trying to find the mode that works for them, and I guess, that's something, but if I can keep things focused on that user level, and so as a user, I can see a benefit. So second thing maybe is looking for the benefit of what we're trying to do. And usually, there's some sort of impact or outcome in the world, where we're really after, and the story's just a mechanism. I think of story, or feature, or capability, similar kind of space, they're all things that somebody can do with a system, but they're doing it to accomplish something. And again, a lot of times people haven't paid enough attention to what success looks like, and be it a metric of some sort or a result of some sort. But it's not a metric about we use the system, it's about we generate more money or we help more people or things like that, that happen in the world that we care about. And the software's incidental to that purpose. A lot of times, people kind of miss that connection, and especially sometimes with teams, I see them a bit disconnected from that. >> Well, one of the things that I've always liked when you, for instance, spoke to my class earlier in the year, where you really emphasized the fact that stories aren't, I forget how you put it, better than I'll put it now, but stories aren't a spec, they're an input to collaboration, and that's their only purpose. So can you talk a little bit about the relationship between kind of prepping those stories almost as a center piece or agenda item for the right kind of discussion and what that discussion should look like? >> Yeah, so I think Alister Coburn maybe early on had the phrase that they're tokens for conversations. So I have index card around, right, always have a stack of them, that early teams doing this, they would just write a little phrase on a card, and half a sentence on a card is not a speck of a system. And so it reminded you in that sense that all you're doing is saying we need to talk about this. And it's not a giant document or anything like that. I would say in general that Agile teams kind of move away from a lot of that to the extent they can avoid it, they'll avoid it. Again, we're not trying to build everything all up in advance and hand it off, we're trying to have more conversation. So getting the team focused together and having that talk and coming to an understanding together, the card's very incidental to that. It just reminds us like hey, there's ten things we're trying to do with the system. And we're going to have to talk about them at some point to make them work. So that to me, I definitely look for that notion there. As far as prepping them, I'd say the biggest kind of awareness that maybe wasn't always there was making sure you have the different perspectives. So you hear three amigos is a phrase with behavior-driven development approaches, but others use it as well. The notion that we need to make sure that there's some sort of user presence, some program product, person, or something, developers, and testers to agree jointly on what things should do. And if part of your prep for before you're actually working on the story, you're thinking about examples that would demonstrate that it works or doesn't work, that part of the conversation can, again, replace some amount of the spec documents that you might have been used to. I think, in some cases, there are going to be written specs for things, and it's not like you're trying to escape that if it's helpful. But so much of the time, somebody writes a spec and then you can't make sense out of what they're really after, you pick up the phone and talk to them and find out what they really meant. And if you're going to have the conversation anyway, the specs is going to get set aside anyway. Let's bring as much of that as we can because we know conversations work a lot better, we can get feedback about what's working and what's not or what we understand, what we don't. Let's take advantage of that if we can. >> Those are some great ideas on the use of stories in practice. Thanks so much, Bill.
