 Alright, so if you can't tell from the shirt, I'm with Pantheon. We're kind of easy to find here this year, I think. I'm going to apologize in advance. This is a short session, and it's kind of a big topic. So the last slide on there is some additional resources and just things to look at, and there's a book on there that I think is a good book recommendation on there. And so we're going to kind of go through things quickly. If you have questions, I'd much rather this be a discussion than just me regurgitating information at you that you can go read. So if you have questions, please feel free to ask them, and yeah, let me just go through. So this is from user stories to use cases to tell the whole story. The idea here is that we all know user stories. We use them frequently in our development. They do have awesome benefits. They have some limitations, and use cases help reduce some of the risks that are introduced by those limitations. I am a senior engagement manager at Pantheon on the migrations lead. I started doing Drupal development in 2007. Word pressed a little bit before that, but we don't care about that. And I've been doing a lot of project management work in Drupal development through all the years, and this is something that I've seen affect projects over and over again, and it's kind of one of those lessons learned things, and if I can help reduce anybody's pain points on these, it's all good. So what is a user story? We have a user, we have something, somebody, right? A content editor wants to associate images with events so that the correct images are used consistently, right? So we have a user story very simplified is as a whatever role, I want to do something. This is a little too simplified. This is what happens though when your developers are writing their user stories and they're in a rush, right? You don't get any details, you don't get anything, they're doing it as a checklist, right? It should be in proper format, it should be something like, you know, as a user role, I want to do something so that there's a value added. Answering the why helps determine if or when more information is needed. So it would be, you know, as a content editor, I want to associate images with events so that the correct images are used for any given event. But even that, it's pretty ambiguous. What's the real purpose of the story? Could you actually deliver that with 100% confidence that it would be accepted to a client because it's still pretty vague? What do they actually want? So you could make it even more specific. Great, okay, so it can be, you know, I want to tag images with the associated events so that they can be consistently used in multiple locations on the site reducing chance of human error. Great, but now we have this huge mouthful of a story and it's better, but there's still limitations with it. So the user stories, they are beneficial for planning, right? For communication, they're actually written, well, we actually do this. So for planning, it can be estimated. It is a small piece of work that can be estimated and completed and marked as done, right? That's, I had that, I don't want to say beaten into me, but I had that, I was scolded many times when I was writing user stories and I would make them too big. Like, no, it has to be something that can be done in an estimable chunk of time and marked as done individually. They make it easy to collect information for them non-technical stakeholders because they're kind of in plain English. Like, as this person, I want to be able to do this thing because, right? That's how we talk about things maybe a little more formal than we talk about them, but it's generally in plain English and, you know, verbiage that people can understand. And they let you focus. They're great for that. They're beautiful for that. You know, you've got the story in front of you and you, people, you know, if your brain is wandering off on all the what ifs, no, you have that story in front of you and you're gonna get it done. They are, however, meant to be selected for sprint development and then discarded. They're not supposed to be a permanent piece of a project. If they're inconsistent in the creation of them, like the one where it was way too simple, which I have, I'm guilty of it myself. I've done this before when you're, you know what you're talking about. So why put in all the details? Except that somebody else is gonna refer to that later and they're not gonna have that information. And it's far too easy to start using them as a checklist for development. I've been lead on projects where, inherited projects where the team had just been completing stories. Check this one done. Check this one done. Check this one done. The end product at that point when I inherited it was completely unusable for the content editors because all the complex things had been done. They were able to do everything except that, you know, Drupal's admin is Drupal's admin. And it's a little bit, you can make things very complicated for the content editors. And nobody had considered that because they were just completing the tasks. By building piece by piece without looking at the system as a whole, you can turn the whole project into Frankenstein or it's monster, right? New stories are added to make up for shortcomings of the past sprints. New team members have their own ideas of how things should work. And it just starts turning into a checklist, pieces that aren't a whole system. So then we have use cases. Which, and I'm one of those people who's always beating the team for budget for documentation time and everything like this. This does involve more time. Which is the thing that I think prevents most teams from using use cases. But hopefully, I can convince you. The use cases takes a look at all of the actors that are involved in the site, including the content editors. Whichever system we're talking about. In this case, obviously we're talking about sites. We're looking at all the systems. So we would be looking at the database. We could be looking at the, I don't even know, logging anything like that where we want to be looking at all the systems. And we look at all the teams that are involved. So in use cases, the actors, we include anyone who is affected by functionality. We have the systems. Each piece that they touch is specified. In the example I have in a minute, here you'll see, I'm only talking about, like I only did an example of a small, just the website as a whole for a system. But obviously if you're interacting with other pieces of systems, you would include those. If you had a payment gateway, that would be another system. And then you have all the teams. You can really get a cross-functional view of the feature and all of the teams that are involved. So a use case for event registration. This is a, so use cases use, if you're gonna use a use case diagram, they use UML as the diagramming tool. You have your actors, I guess I can't really do that. You have your actors. And you have your use cases are all here in the center of, within whichever systems they're in. So again, this is a simplified use case. We're only looking at one system. But we put all of these use cases in here. And this gives us a kind of a defining scope of this feature that we're looking at. So after that you pick one of these. And the one that I did is register for an event. I decided we would go ahead and talk about that one. So here, we'd start defining the actual use case itself. The actor we're looking at here is the site visitor. Cause I wanna look at the site visitor registering for the event, not the site admin or whatever registering people for an event. Which would be another use case. So here we have the success for this would be that the site visitor is able to register without assistance from support or anybody else. And we have preconditions. We have that, an event is occurring in the future. It's been created, it's been published. Great. The event has open registration space available. Awesome. And that the site visitor has an existing account on the site, which is an important precondition here because there would be another flow if they didn't. So post conditions, and this is what we want. So the preconditions are kind of like just assumptions. The post conditions then are what is, what state we want things to be in at the end of this use case. Which is really nice for, again, looking at the system as a whole, what things are affected by this. In this case we know we want the site visitor to be registered, but we also want the registration count for the event to be increased by one. So we want to make sure that we know that this is going on. And I have, there's so much more here that's left out. Things like notifications, you know, you'd probably want the site admins to be notified about a registration and all that kind of stuff. I didn't go into all those levels. Then we would define the steps. And if you've done workflows, this is exactly that. What is the workflow? So they come to the homepage. They, you know, where are they gonna click? Where are they gonna do? What's the site gonna do? And we have what we expect their flow to be. And this is what we're going to be developing against. We also want to make sure that we know the alternative flows. So we have things like 4A. Well, if we go back here, 4 is that the site event, sorry, the site displays event information. And 4A then, oh, these numbers got messed up. I'm sorry, I changed that. So this should be 5A. The site displays that the registration is full for the event. If the event is full, they can't click to register. So we want to make sure we have an alternative flow noted there. We also have in here, and again, I apologize, the numbers are mixed up on that. And before I put these up on the site, I'll make sure those are updated. But the site visitor verifies their contact information. Well, what if they don't just verify it? What if they update it? So we want to make sure that we note in there that there's an alternative flow that they update it. And so we have to make sure that the system is going to accept those changes and all of that, right? We bring it all together, right? So we have all of that information ready to go for each one of these users, the use cases, right? So it's time-consuming to do that. However, it is so worth it because we now have a place that we have all of the outlines for QA and testing. That's already done. We have documentation on the feature that you can deliver. It's already there. How does it work? Right here. This is exactly how it works. And we actually fully understand the scope of the feature. The, it ties in with the user stories beautifully. And this is what I love because you still use the user stories because now we can go back into here and we can say, okay, the user story clicks on, sorry, the site visitor clicks on the desired event. So say we're already back here really early on at three. So we know then that the site is going to display these upcoming events. So there we go. That's one user story. And then we're going to have that if they click it, they're going to go to the event detail page. So now we have another story for that that's going to be implemented. And you can do your user stories off of this and then know that you have a full picture of the system instead of just a checklist of functionality. It all has to work together within this flow. It prevents the team from basically developing individual solutions piece by piece. You have the whole big picture. All right, so I flew through that really fast because I want to make sure that we could actually talk about it. Do you have questions? Because this was, again, really high level. And I would love to have more time to talk about it than to just regurgitate. Yeah, I guess so. So just based out of your experience, where in the process do you go from defining user stories and then saying, okay, now let's create the use cases? Actually, I do it in reverse. So you do your requirements gathering and everything like that. And right from the requirements, I do the use cases and that always flushes out more requirements. That always flushes out more questions, more everything. You get so much information because there's so many. As you're writing that out, you realize how many assumptions you're making. And especially to have a stakeholder review those is great. Downside, limitation of them is if it's non-functional, like not user functionality, it's hard to capture in a use case. And they're also a little bit harder for stakeholders to kind of digest. Like user stories are real simple to digest. These are a little bit more involved, but it really does flush out the... This is probably a basic question for somebody who does this all the time. But I'm curious how you fit in the requirements that come from user experience compared to the requirements that come from a business analyst, which comes first or how you fit that together. Right, and that's exactly it. You have to pull it all in together. Like if you have... And again, this is very user workflow, right? This is their experience. But when they click that submit registration, what's happening? And that's what this one's missing, right? This example is really just on the user experience. But what's happening there? And that's where we would put in the... We see that the site sends a confirmation email to the site visitor, but what about on the back end? Are the business needs that have to be accomplished here? So that would be in there. Yeah. Yeah, I'm sorry. I suspect because they're recording it, they wanna actually make sure they hear the questions in the recordings. So I'm just wondering how you feel about moving user stories to separate sprints. So if a user story's in completely done in a sprint, even though most other user stories are completed, how do you feel about that? Technically, against the rules, right? However reality happens. And I think it's important that you work with your team though and you figure out why. Like why wasn't it completed, what happened? And you shouldn't have stories that are spanning sprints because that's the whole ideas to have your deliverable at the end of the sprint, right? So yeah, I mean obviously it's not supposed to happen. We all have it happen. A lot of communication with the team. And I think, again, this is where having the user story, the use cases, sorry, too many U words in there. Having the use cases helps because of all those assumptions that were made in the user stories and why is it over, why wasn't it completed? Because somebody made an assumption and their estimate was off. That's why it's not completed, right? So if you get rid of all those assumptions and you can actually accurately estimate the work, your sprints should be completed on time. Awesome, and then one other question. How do you break out your sprints? Do you do it on functionality or how do you do that? Because sometimes we do it on, if we're doing the e-commerce portion of it, then we're doing enabling commerce module, doing all of that stuff and then breaking it up into that, do you do it another way? It really depends on the stakeholders and what they need is deliverables, right? Because you have to be working in that system. They're milestones. Yeah, I've seen these sprints be so limited to exactly, like you're saying, is that functionality pieces, but then I've also seen it just as in, we need to have a deliverable to the stakeholders. They need to see something and do it that way. Any other questions or, yeah, go ahead. Absolutely, please. Like I said, I'd much rather talk about all this than just kind of, yeah. So we don't do this much right now? Yeah. So between the project management team and the design team and development teams, who does it make the most sense? Like who should be owning, like the user stories and use case diagrams and things like that? Who should be owning that information? Ideally, if you have the project manager who's actually the owner of the project, it would be them, but so one of the things to note also about these cases is they don't include design, right? That's excluded from here. Like we're not talking about design in here and we're also not defining solutions in here. So it really is across team then once you get to this point and you understand this, you have to work with all the teams to bring that whole system together, right? So again, it's encouraging communication and it's encouraging the full picture, get the full story there instead of piece by piece. So you don't have each team working individually and then at the end, it doesn't come together, right? Right, another question. So is this meant to be used more internally, like between teams for communication or would this be something that one would share with the client? Oh, I would totally share this with the clients, especially not that they're out there frequently, but occasionally you come across stakeholders who are very worried about their babies and are in panic mode about everything. This calms that down so much. This is absolutely such a lifesaver if you have a high needs stakeholder. As soon as you hand them this, again, you have all the documentation, they can see what you're testing against and right there they can say, oh, that's not actually what I meant, instead of after you've already done development work. So it is doing more work ahead of time. It's that you have, and it's the hardest thing, I think, for teams that are excited, right? You're excited about a project, you just stop and freeze and do all of this planning ahead of time, but again, it makes the sprint planning so much easier, it makes deliverables so much smoother, just the delivery is so much better and again, stakeholder management. So all over the place, it's just a benefit. Thank you. Yeah. Do you guys use these to roll into B-hat tests and stuff because it seems like it would be super handy for that? Right, exactly. How do you carry them forward after development? Yeah, I've had teams that did that, so I'm not doing any of that right now, but that is definitely, and that's exactly it, you can convert these into testing and everything, it's just perfect. And ideally these would all, you know, you would keep these, wherever you keep your project documentation, this would all live together and as you are working on your features, you would do this for each feature and then you would have actually documentation of the full site and the full system, and then if somebody comes in in two years and three years, whatever, and wants to make a change, they actually have all this information ready to go. They have, these are incredibly useful for just like looking through and saying, oh, this is already here and defined somewhere, right? This gives them that really high level view of how is the system working, what's going on, oh, I don't actually need to recreate this because somebody did it, it's just not being used right now or something like that. Or if the registration process was, if they're gonna start charging for registration, they could look into any of the user stories, the use cases, I'm sorry, the use cases around the registration and talk and then add in the gateways into there. So it's all, this is meant to be persistent. And again, the user stories are not meant to be persistent, you mark them as done and it's gone and it's off your board and into nowhere land. This is documentation for the project that's meant to be permanent. Any other questions or anything? One thing I've come across a couple of times, I'm wondering if you've got a special way of doing it is the error cases. So we've got a great use case, but we're not talking about, well, the user did this wrong, the user did this wrong. And sometimes assumptions get made about what you do when that happens. And that ends up being like the Achilles heel of the entire project. I was wondering if there's a special way to capture that. Yeah, absolutely. So that would be in these alternative flows, again, for anything where they do something wrong. Like in this case, we said, okay, the site visitor updates their contact information. Well, what if they put incorrect information in there? Or what if they, you know, we're not talking about like editing or anything in here. Like there's, if something goes wrong, if there's a chance, if they have an option to do something stupid, it should be noted in here. And you should have, you should document that and have it noted in your flow then. So it does kind of capture all of those, ideally. Yeah. And again, it's, I mean, it's the same thing with the user stories, right? If you're lazy and you don't put the effort into doing them right with the details, they're not gonna be useful. If this is just another thing that you're just kind of, you have to do it and you're not actually putting the effort into actually capturing the errors, capturing the whole system, it's not gonna benefit anyone. And it is gonna be a waste of time then. But if you put the time in, it is so worth it and it has made so many projects so much easier. Have any of you used use cases before? Okay. Have you found that they helped? Yeah. I mean, it's just the difference between, it's just, yeah, I'm clearly unbiased in a fan. But anyways, there is a ton of documentation online about use cases and user stories and everything. I would recommend, I mean, even Wikipedia has a ton of information on it, which is really funny. I would recommend taking a look at any of those if you're interested in more details. And then there's an awesome book. It's from 2000 and I don't know if there's a more recent edition. I didn't see anything. But it's called Writing Effective Use Cases and it is, it's great. So that's all I've got. Thank you. So hard to do anything in that.