 good morning everyone we are here today for a really quick version of telling the full story about using use cases and user stories my name is Lauren Kelly I'm a senior engagement manager at Pantheon systems I lead the Pantheon migrations team this is actually more drawn from my experience as a developer than it is from my experience currently at Pantheon so a lot of this is more of information that was drawn from my past then what I'm currently doing so I'm gonna go through this pretty quickly this is usually a much longer deck I've trimmed it down but covering a couple things one is a quick introduction to user stories a quick introduction to use cases bringing it all together and then I really prefer to have a kind of discussion about what people are using what's working for them and things like that so if we can and with that that would be amazing so first up user stories so I think we're all very familiar with user stories as a user role I want to do something so that some value is achieved so for example here we've got as a content editor I want to associate images with events so the correct image is used for an event right so they're not mismatched really that seems like really basic and easy the question is is that something you could actually deliver with confidence does it have enough information is everything there that you would actually need to do to put that in place for your project so there's certain benefits to user stories one on this planning the work within the user story can be estimated reliably used for sprint planning right so if we go back to this example here where we're talking about a content editor you say okay we could this doesn't really have the scope defined this is actually a really weak example with just these three pieces here but we could refine this we could scope it we could work with this and get a good estimate and put it in a sprint and know that that work was going to be done it is also makes it really easy to collect information from non-technical stakeholders because it's kind of written in plain English right you can it's a little awkward it's still did but it's very it's like just how you would normally say hey I want this I want to be able to do this okay why do you want to be able to do this well because you know and you get that information right it also allows the team who's working on the stories to stay focused when you've got a task in front of you a user story in front of you you know this is what you need to work on this needs to be completed and you can do it however there's also limitations to using user stories they're really only meant to be used for sprint development they're meant to be developed for that specific task of estimating work for a sprint putting it in there and moves through the stages of the sprint and then discard it they're not meant to be a permanent resource for the project documentation the other limitation which I kind of hinted at before is that if the team is inconsistent in meeting requirements for the user stories they allow for scope creep so in that example that we had about the content manager you know working with the images and things it doesn't define like what content types are we talking about of you know are there multiple event types are there multiple image types is it a field anything like that are they being are they being tagged or how are they being you know there's no scope in there or anything like that that could grow into a huge story or it could just be a really basic one and you don't really know that you can't really deliver that one with confidence and my biggest complaint about using user stories and this is one that I saw all the time when I was working in agencies was they're very narrow-sighted it's extremely easy to slip into using user stories as a checklist to be completed and you know when you deliver this without ever looking at the big picture there were multiple projects I was on that I would be running through I'd be kind of inherit projects and I think we've all done that and it's always been interesting you would see the stories listed in the done column of whichever you know management system you're using and you'd look at this the go into the site and look at it and work on it and you'd see that it's completely unusable by the end user like there it was too complicated they had to go through 14 steps to do something that was incredibly basic all these issues because nobody looked at the big picture and they were just delivering by checklists of user stories so that's how you create a monster site in my mind if you're building piece by piece that looking at the system as a whole you get all these pieces added on somebody comes in they say hey I want this functionality I want this functionality it's added on without any thought about how it affects the rest of the site how it affects the users using the site and all these things like that so that's where we bring in use cases so if we back up a little bit if you consider each project a novel or a movie or a story you know if you consider it as a whole entire thing imagine if you didn't know all the characters and their storylines if you had to rewrite an entire section of a website which is what we're asking developers to do if they don't have the big picture every time you introduce a new character in there every time you come in and you know Frodo walks in and out of a scene or anything like that or Gandalf is here or there you every time they have a new interaction if you didn't know that that was coming up in the future you'd have to rewrite everything to make that work we want to avoid that so use cases provide the storyline they tell you who will be doing what and when and where they'll be doing those things in the in the big picture so a use case consists of multiple pieces of documentation there's a diagram that displays all the interactions between the actors and the systems so part of what I cut out of this to keep it a little bit shorter is the discussion about personas if you consider when you're doing a project if you create a persona as your actor who's doing things it's like creating a Dungeons and Dragons character for your projects that's the fun part for me but then you're basically saying okay what is this character going to be doing what is this actor gonna be doing and we create diagrams that say everything that the the actor is going to be doing and then you create a list for each of those actions for each of those interactions you create a list that has the step-by-step list of all the steps step-by-step all steps their alternative steps like what you want what path you want them to follow what alternative paths there are what options you want them to have and you have to also consider the things that you they might mistakenly do so if you have the user filling out a form and hit the back button instead of the continue button what's going to happen is that data could be lost is going to be stored how is that going to be handled and then finally you also have a document that contains information about the primary actor the goal the preconditions the post conditions and definitions success so it's a big piece of it's a lot of work and then I'm not gonna lie to you doing these is a lot of work if you do it up front it is worth it so that's my that's my argument here at least so this here would be the diagram of all the different interactions that all the actors would have right we have a site visitor and we're gonna look at their registering for an event so here's a sample steps of a site visitor registers for an event here's the steps we want them to follow you would also again have like an alternative path here where if we have in step seven here that they complete the login well they needed to do another step of verifying their we have to verify their contact information so they're running existing user they're logging in if instead they were a new user so the new user registration would be an alternative path on this and then finally we have this piece which is one of my favorite pieces of the documentation for it for these you have the summary of the actor who who were we talking about what are they going to be doing what's their goal what's success mean what are the preconditions what assumptions are we making and what do we know how do we know when it's done what's success look like now in none of this are we defining how solutions will be implemented this is purely about the problem to solve are you know what steps you know what it looks like when solved and what it looks like you know before and after basically we're not talking about what the actual solution is here so the downsides of use cases we've all had projects close that everybody's really excited about the dev team wants to jump in they're ready to go they have this great idea how to implement the solution they have to slow down you have to stop at that point gather the information write all the stories you have to work with your teams and talk about what do the stories mean how do we define these what does this look like as the big picture it's time-consuming and typically one person can't do it you do have to delegate you have to work with your teams and you do have this you need a system to keep all this organized however when you bring it all together once you build this all out you have the ability to then write user stories that answer all of those steps all the stages all those questions of how you have a user story that will resolve that you can implement that into your sprints and know that things are going to actually you have fewer blockers because you know that you have that big picture of the whole story you're not wondering what's going to happen if we make a change how is this going to affect other things things are going to you know you're going into a sprint knowing what the blockers are instead of finding it out halfway through the sprint the scope of the project's been thoroughly defined you can easily at that point say hey what functionality if we're we're over budget you know we're already used up all our hours what functionality can we like trim out what's the how can we prioritize this it's really easy again like when you have the examples of something like this to go to the stakeholders and say how critical is this piece how badly do we need this and obviously this one would be important but how badly do we need this can we lower this on priority and put it in in another round of development and they can see them how it fits in that big picture too we also have this glorious thing that I love to if you go back to this one this can be turned into your be hat testing basically to base you just turn this right and even if you're not using automated testing if you needed to turn this over to your QA team you've got this all available right there to them they know exactly how things should be working and they also if you've done all the documentation that goes with this of the alternative workflows and the mistakes and everything they can follow all of those paths and see and make sure that everything is taken care of and then obviously you have this entire document that you can share with stakeholders you could hand this off to another team if you brought in a new developer if you brought a new project manager if you brought in anybody new to the project the stakeholder left and came anyone came in you could have all of this documentation in there without questions about you know what's priority what's this who's this who is requesting this why is this in here it's all in your documentation the biggest thing which I mentioned is this is time-consuming at some point you have to stop documenting and you do have to start doing so this is even though this is obviously supporting an agile process this in itself is an agile process if something is missing you need to add it in but now you can add it in without wondering how it's going to affect other pieces you can check to make sure that it isn't affecting anything else or if it is you know it in advance you can update each of the other affected areas quickly and easily so that your documentation is up to date and you can adjust upcoming sprints with new user stories that's the best way to keep being awesome and tell the whole story and then I just have a couple of quotes because this is actually the stopping the documentation is one of the biggest things for me I always have this sense of once I start documenting a project I actually want to have everything documented but honestly we've got here the pursuit of perfection often impedes improvement you have to get started to know what needs to improve and what needs to change and if I wave with if I waited for perfection I would never write a word and that's exactly the point too you can't have everything perfect it has to be a living document the or the whole plan has to be a living plan you need to be updating you need to be revisiting it it's not a one-time look at it complete this check it out the window it's a it's a piece of the project and needs to be treated that way and then I have got some resources here primarily on creating use cases I mentioned personas there's a link there on personas gather space has some excellent documentation on use case examples and honestly the Wikipedia link is it's fantastic as well I was impressed by that and there's a book that I've always enjoyed it's by Astor Copburn it's not I don't know if there's a more recent addition than this one but it is a is a great book for learning how to implement this into your process so is anybody here currently using use cases in their projects have you found it helps does it make a big difference like do you find like it's easier to write user stories and things like that yeah but I do find that it is time-consuming basically and I'm a team of three people from the project manager like two developers so it kind of lands on my shoulders and really we just want to get started on doing the project yeah and in case you couldn't hear that that's just basically what I was saying is time-consuming and that developers really just want to get going when something comes through especially when they've been consulted on it before it closes which is ideal yeah I think we can we use the mic for that just to make sure that they're it's part of the recording and everything is that possible can you come up to the mic I'm sorry I should mention that I know I'm sorry I was wondering because all this when I banged to the use case and shy we need to research to start before we start working I will say that the hours you put in in front you will subtract in fixing stuff for doing stuff again in the when you're coding right yeah yeah definitely and that's why you're not only saving it on coding but you're also saving time on when you hand something off to the stakeholders it's what they were expecting and it works the way they expected rather than it being like you hand it you deliver this thing that you've worked on for hours and you know your whole team has been on from you know a month or two or three or six and you hand it off to the stakeholder thank you and you know they're shocked and surprised and this is not at all what they were looking for we want to avoid that as much as we possibly can yeah can you do you mind coming up talk very loud is there a way you can use a template because I can imagine like some of the processes are very similar in various projects I definitely use templates definitely so if the sorry my musical rock up here obviously these are you can't really template this part you I mean you could copy and paste this for anything like different stages of it of each piece of the project you could copy and paste this if you've got the same actors and just change what they're doing but and this is already basically a template like the the full version of this has a couple other steps in it right it has the the steps defined the alternative steps the you know what you don't want them to do and identify those issues and things and this though is definitely templated and oh this is what I this is the structure I always use and always fill out as you know defining that and yeah I could just copy and paste like once I start on a on a piece and I'm defining these I just kind of copy them and then just edit them for each little piece I'm talking about mass produce and then edit I really do try to encourage my teams like I you have to delegate this out so if you know that this is a piece that someone else is the you know you have a developer who's going to be working on this piece if you can't sit down with them to work on it together which is ideal but if you can't then have them at least you know do it and then you can review it and move forward it's horrible for developers and I'm so sorry for suggesting that they do it but if they are qualified to be able to you know go in say this is what I'm envisioning when we're talking about this piece this is what I'm envisioning and then you know ahead of time to this doesn't match up with what the big project is but somebody does need to own it and make sure that's all cohesive I have a question in the agile process you do battle for refinement you get a fix you get you stories and you go into more detail where does this relate to the moment when you start writing this because I see you writing use use cases and then adding user stories right exactly so this is before you start doing the user stories and then if something needs to be refined you mentioned you know you start the user stories and then you were fine there's a refining process as you go through when you're doing if you have this done in advance you can then refine without worrying about how it's going to affect the other pieces you know in advance if that's going to cause a conflict later on or with other work that's being done in that sprint especially you still use the use the user stories to define sprint and yeah exactly you do this then you do the user stories estimate the user stories and then work with the implementation that way and follow your normal workflows so it's just kind of all ahead of that to make sure that your user stories are all together okay I think we are just about out of time is that you need to set up for one more question okay anybody yeah as far as can you right so if you have the story the big story to find then you can break down into these little pieces especially with the preconditions and the post conditions and then from there the user stories are going to talk more about the when you're doing again the refining of the user stories you have the user story of this user wants to do this well how are we going to talk about that and that's when you talk about the solution and you have again you have the big picture as a reference so you have all of this in your mind as you're doing that so you could say okay what actually will handle all of this together since all these pieces are interrelated for this functionality how do we consider all of that together and come up with a solution instead of looking at just the one piece and doing a solution thank you tomorrow not tomorrow Thursday there we go thank you so much