How To Use Story Points in Agile and Story Point Estimation

[Music] hey everyone steve here from programmingmadeeasy.com and today i'm going to be talking to you guys about story points so story pointing is something that we do in agile to try to quantify the amount of effort uh or sometimes called complexity of the stories and things that we're being asked to do in our code base right like trying to fix a bug or trying to implement a new feature those type of things we typically are trying to quantify the amount of effort it's going to take in order to deliver on those things and so we use story points to kind of give some sort of numerical value or impression to the management team about the amount of effort that's going to be required in order to do this thing so i'm going to transition over here to my slide deck now the name of this talk is called a three-dimensional story pointing a rubric for story pointing and refinement and again i do want to emphasize that this is going to be about story points and about you know agile but also i want to give you guys a rubric some sort of uh thing that you guys can use to kind of analyze and look at these stories and help decide and determine what some of the challenges are about accomplishing that story and finding ways of using those different um those that rubric to find ways of making the stories easier to work with and easier to do okay so that's what the rubric and this talk is going to be about is you know not just figuring out what stories are for uh or or the purpose behind them but also what is it that you guys can do a kind of a rubric to evaluate these stories to help determine a direction for the team in resolving some of the challenges so um without further ado uh by the way this is going to be a fairly slide deck heavy talk i don't really have any code to discuss but there will be a lot of concrete examples throughout this thing um so there will be some some bullet points on things but just really to visualize the talk as i go along so if you wanted to just listen to this uh in your headphones and shut off the video you certainly could but i do think that the slide deck is very helpful in illustrating and cementing some of these concepts all right so let me just real quickly go through the objectives of this talk um so the first thing is we're going to talk about the purpose of story points and just kind of go over why do we do them right what why do we have story points what is their purpose then we're going to talk about that rubric that i was mentioning before i call it the three dimensions of difficulty you may have heard me use this term before in other videos you may not uh but it is a rubric that we can use and apply to these stories to try to define some of the challenges in fixing or in accomplishing the goal of the story and then we're going to talk about looking at each one of the different dimensions on that on that rubric we're going to look at each one of them and inspect ways of how can we resolve those issues if there is a challenge on one of those dimensions what are some of the strategies that the team can do in order to resolve those issues so we're going to do that and then we're also going to just kind of do a little wrap up conclusion here and just kind of go back over what it is that we learned so um first and foremost let's talk about story points and their purpose uh because this is obviously a big big piece of this right what what is the reason why we even have story points so story points are a reward right story points reward team members for solving problems based on difficulty not time spent this keeps team members focused on shipping value not on spending time now this is a statement that i took directly off of the atlassian website so this is what they have to say about it but i really really like what they're saying here and those of you who are not familiar with atlassian they are the creators of the very popular ticketing system called jira they also write confluence and bitbucket they have a whole suite of different products that are useful for agile teams trying to do agile software development so if if you're not familiar with atlassian they're a very well-known company within this particular space and helping teams be agile and this is what they have to say about story points i really like this again story points to reward team members for solving problems based on difficulty not on time spent and this keeps team members focused on shipping value not on spending time so you'll see there's this really heavy emphasis on avoiding time right avoidance of time but there's one thing that i actually really keyed in on in this statement that really kind of clicked for me and that was the use of the word difficulty right on that top line the very last word is difficulty if you've ever worked in an agile environment and you've tried to do story pointing before chances are the word complexity came up right how complex is this story but i think difficulty is a much better word for this and i understand that there's that those two terms are pretty synonymous uh but to me i think difficulty is a bit more of a broad term whereas complexity has a little bit more focus on the the the challenge itself right how complex is the problem whereas difficulty i think is a bit broader of a term that expands out to external forces external things from this from the complexity of the story in and of itself right so we can kind of turn outwards away from the code or away from uh from the challenge of of the question or the work that's being done and actually notice that hey there's other pieces to this effort that need to be factored in in order to determine what the level of effort is in order to deliver on this story and so i really like that term difficulty i use it much more than i use complexity and you'll actually see that i still use do use complex but i use it in a completely different way that i i think will probably solidify your guys's knowledge and understanding uh and and that has a lot to do with the rubric so aside from the fact that there's difficulty i want to focus here on their kind of avoidance or really expressed way of saying look guys story points are not about time they're not about time they're about shipping some sort of value to the customer that's what story points are supposed to represent is the difficulty of the problems that are being shipped to the client okay that is what the point of story points are and when it comes to the association of story points to time this is typically done i think because management has this really heavy emphasis on meeting deadlines right when can we deliver on this when can we ship this thing when when will we know this particular feature is ready to go and and that kind of thinking is really a reflection of this command and control kind of waterfallish system where we plan ahead of time and have some sort of due date at the end whereas agile and extreme programming really focus more on continuous delivery right we're continuously providing uh iterative change we consistently provide new things and and implementations that provide some sort of value to the customer and it's not about providing this one block of code and delivering on this set date but rather making incremental changes that are better and better uh for the user and providing more and more value kind of a growth of the product rather than a delivery of the product right it's it's about growing the system to make it more valuable to the customer and it's a really a very different mindset that is difficult to uh it's difficult for management teams to understand and comprehend and put some sort of uh uh wrapper on so that they can compartmentalize it and explain it to their higher-ups right or to the customer about delivery and and what's going to be received so uh this is kind of where that struggle starts right of of what it is that the team is doing and the value of the work that they are doing compared to this delivery date mechanism uh that a lot of management's looking for so what i really kind of want to point out here is if if you're using story points to try to quantify time what you're doing is you are not effectively using story points for their correct purpose you're muddling you're muddying the waters of what a story point means because if your management is asking the development team to attribute some sort of story points to a story but that actually is a representation of time then you're not really focusing on the difficulty you're not really focusing on the amount of effort to to solve this thing and just to give you kind of an example here let's say you have two different developers that are going to focus on exactly the same problem does that mean that the problem is any more difficult for one person or the other no it's the same level of difficulty for both people but one person might have the skill set to or or might stumble upon the answer or solution a little faster than somebody else but that doesn't change the difficulty or the amount of effort required in order to do it it just means somebody came across the solution faster or slower than somebody else might and the very fact that it can take two individuals different amounts of time to come up with a solution to the exact same problem means trying to associate this with time is fools is a foolish notion right we cannot do that we don't know we can maybe estimate like this person this person and this person each individually might take different amount intervals of time but guess what if you put all three of them together in the room working on the same problem at the same time they might take even less time they may take more time right so trying to associate solving a problem with time is just a foolish notion to begin with it really needs to be done away with all together it's hard to do though i understand because most of us are under some sort of management pressure to set a a deadline and deliver by some sort of delivery date uh and just know story points there there are other ways of trying to manage that and figure that out but using story points for that mechanism i think is a very foolish notion and that's really we've had decades and decades of people trying to do it that way and for decades we've had no no actual solution i i really highly recommend there's a book if you're interested at all there is a book uh it's called mythical man month let me switch back over to um to this view here so you guys can see this uh this is a really good book i recommend everybody to read it's by uh frederick book brooks it's called the mythical man month um yeah i just so happen to have it here on my desk uh it's that important to me that you guys read this book it's really really good it talks about that mythical idea of a mammoth how much knowing how much time it's going to take for a development team to produce some bit of code it's just foolhardy it doesn't actually exist no matter how much management wants it to happen okay so anyway i've been talking a lot about that and i i can't really emphasize that point enough uh again story points are not about time and if you start to try to associate them with time it really starts to uh to force the developer to think about things in the wrong terminology and kind of juggle these separate balls in the air at the same time about you know is the story difficult or is it going to take more time and which one of those am i actually pointing off of uh makes it really hard so um some additional points that i want to make about story pointing um story point stories should be pointed according to complexity unknowns and communication but not time okay so we have these three different dimensions here that i mentioned right complexity unknowns and communication so we talked a little bit about complexity before complexity is kind of the the solution right how difficult will the solution actually be that has more to do with the the code that needs to be implemented or the reasoning about the code that needs to be implemented that's kind of the complexity quotient of this right then there's the unknowns and when we're talking about unknowns we're thinking about things like what if there's an api that i've never encountered before i need to go read the documentation or maybe there's a new framework that i need to implement and i need to go work with it a little bit uh or again with an api maybe i have to like test out creating some sort of client to go talk to the api so that i can see how to how to work that kind of thing because i've never maybe i've never worked with the clients in apis before so if there's an unknown to the developer that adds to the level of difficulty to accomplish that particular thing right and it has nothing to do with the complexity of the solution but it does have everything to do with the difficulty to deliver that thing so just kind of going back to that the difference that i make the distinction that i make between complexity and difficulty complexity is more about the scope of the code and and the reasoning that you have to do about the code that needs to be written whereas unknowns is a completely different dimension of difficulty that is about exploring things about finding out and discovering what what are those components that you don't yet know about and you have to go solve those problems before you can even start writing the code and then the third dimension here that i mentioned is communication right and and this is about third party communication talking to somebody outside of your team typically you know talking to a customer and trying to get better better uh requirements from them better stories written from them understanding more about the problem from them maybe you have to talk to an external team uh you know maybe you're working on the front end but you have to work with somebody on the back end in order to get them to implement something and you have to convey that information to them uh maybe there's a dba that you've got to go talk to to set up some database tables right there's that has nothing to do with the complexity of the problem that has everything to do with someone else that you have to communicate with in order to accomplish the goals of this story and that needs to be factored into the difficulty the amount of effort required in order to accomplish this story it's not just a straightforward answer of this is a complex problem and i have to write this code to do it there are other factors involved here like the unknowns the things that need to be explored and understood and then there's the communication aspect if you have to talk to somebody outside of your direct team right you have to talk to another team in the organization another customer uh or maybe it's an api that you're communicating with and you've got to go talk to the the creators of that api right if there's some sort of external communication involved there that adds to the level of difficulty and that is a different dimension of difficulty okay so uh story points are a tool for determining if stories are small enough and that's one of the things a story stories should be small enough to do right and you can use story points to decide whether or not a story is accomplishable because it's too big or too or if it's small enough so you can look at the amount of story of story points that you've attributed to it and decide you know what this story is not ready for us to work on it and i'll talk a lot a little bit about that later on one of the other things that i like to point out with teams all the time is that the only actual known time quantity and i'm going to go back to this argument about time um the only known time quantity thing that you and your team actually know for a certain regarding time is how long your current iteration is how long is this current iteration and that's not future iterations that's not you know hey we have uh three week iterations or two week iterations or one week iterations like that can change right you can go from a one-week iteration this week and then at the end of this week your product owner or project manager may may come to you and say hey we're going to change this up we're going to make everybody go to a three-week iteration now and and so the only thing that's really a hundred percent certain is that your current iteration ends on this day right like that that's the only thing time wise that you truly know about you don't know how long stories are really going to take you don't know how long it's going to take to explore those unknowns you don't know when charlie is going to get back from his vacation to respond to your email you sent you don't know how long it's going to take for that story that you passed along to the dbas to complete so that you have the tables to work with like none of those things are truly definitively known even if they give you promises oh yes i will have this done by uh by thursday you can count on it well thursday rolls around quite often and it's still not done right or you think about thursday and it gets delivered at the end of day on thursday so you missed all of that thursday there's really no set time quantity that you can be absolutely certain of other than really the the iteration that you're currently undergoing right any future iterations could change and the stories themselves we don't really know how long it's going to take okay and then the last point that i kind of want to make about on this slide here is there's really no such thing as a zero point story okay and i say except for spikes don't talk about spikes they're kind of an interesting little caveat that really relates to something else that i want to talk about later on but uh there's really no such thing as a zero point story and if you think about this i think most of us inherently already recognize this um especially when you start thinking about story points are about effort and difficulty and things like that that would theoretically mean you could have a thousand stories in your backlog each of them is zero pointed and it should take you there's no level of effort involved in doing them and if that's the case if you have a zero a quote unquote zero point story my question would be why is it your responsibility to do it if you know you guys are the software developers you guys are the experts with these certain sets of skills to resolve these difficult problems and put forth some sort of skilled effort to resolve if this is truly a zero point story that requires no effort and is not difficult it really shouldn't be something you guys are trying to tackle somebody else can do it right somebody else who whoever gave you that story should theoretically be able to do it because it's zero points it it there's no effort there's no difficulty there's no challenge here for us to do it if that's the case then why are you doing it why is it your responsibility as a software developer to tackle things that have zero points and again i think this also relates a little bit to the statement that atlassian puts up there you know about delivering or shipping value if if you're saying that a story has no value then again why are you doing it like if there's zero difficulty there's zero challenge there's zero value to this why are you doing it why isn't it someone else's job to handle these kind of menial if you will tasks that don't really have anything to do with your job or the complexity of problems that you're trying to solve you guys are the experts being paid very well to solve problems and if you're being if you're receiving zero point stories it seems like a pretty wasted effort it seems like it's not really worth you know the resources that are being applied to solve that problem and i i realize i don't really like the word resources in terms of people i don't think that that's a very humanizing term but i just want you to understand this is a very poor allocation of your time if they're trying to tell you to tackle zero point stories because that just wouldn't make sense instead you should have some sort of baseline value minimal value that's associated with a story okay and and i again i'm going to make a caveat here for spikes we'll talk about spikes they're a very special category that i definitely want to tackle but when it comes to an actual user story they should have some sort of point system right should be some sort of value that uh or difficulty and effort that needs to be required to resolve them okay so um let's talk about a user story what would a good user story look like this is something that i think we need to fundamentally start with is what should a story look like so that we know what it is that we're pointing uh and and i i like to break down stories into three questions there's who there's what and there's why so the who of a user story is typically written in this kind of format like who would be the as so as thomas as joe as joan as kamala as whoever right as this person right that is who this is for that is who this effort is going to be for then we say the what right so what is it that this person wants to be able to do in the system and so we write that out in our user story as the i want to phase so we're kind of set putting together here a template right as so and so i want to do this thing and then you finally have the y so we have who the what and the why and the y can be expressed as so that i i can do this i can do that right whatever the value is for that particular user so this is a very well defined this is a very common template you'll probably see in a lot of places if you're if you're looking for how to write user stories this is a very common template as so and so i want to do x y z in the system so that i can do this right so a a pretty common example and i just want to i just want to kind of talk real quick here before i get into the example um how is not a part of this right how this is accomplished how it is that this particular piece of software is written is not a part of the story okay we don't do that we do not include how this is supposed to be to behave right or how how you write the code or the technical specifications of the code or some sort of technical detail is not expressed in this story it's strictly about who the what and the why now a good example of this would be a story like this as thomas okay and thomas would be a persona uh i want to be redirected to the account page after submitting valid credentials so that i can view my account information so we're using that template as so and so i want to do this so that i something right as thomas i want to be redirected to the account page after submitting valid credentials so that i can view my account information this again i want to point out i i can't stress this enough because this is a mistake i see a lot of development teams have in their story writing there is nothing no mention whatsoever about how right there's there's uh there is one little thing in here about the fact that we have an account page but what that route is is not in here right but what is the route i don't know it doesn't really matter it might be something you want to mention but it's not a technical specification it's not really that much of a requirement for the user to understand this um and so that i can view my account information again that has really nothing to do with the software developers we're not looking at implementation details we are instead looking at from the user perspective what who is it what are they trying to do and why do they want to do it that's really really important to do so that big common mistake of trying to figure out some sort of technical implementation detail that gets shoved in here i'll see a lot of teams doing that another thing that i see a lot of teams do is they replace this persona of thomas with developer so they might say something like uh as a developer i want to implement a uh you know unit testing across the board so that i can be confident in my code right like that's that's just taking a technical specification and jamming it into this format and that's not what the purpose of stories are for they're not for the developer they're for an outside person there for some sort of third-party customer some sort of user that is going to be interacting with your application right whatever that application boundary is that you work with they are interacting with your boundary with your system and the stories need to be presented in that way and there's a very key reason why we do this user stories are not about the developer they're not for the developer to understand the technical specifications and requirements and that's the most common thing that they're misappropriated for stories are about communication between the client and the developer and that means they need to be understandable by both parties if you are writing something that is a technical specification in the user story only one component of only one party of that that's reading that story will understand it right if it's a technical specification then the user will not be able to understand why right they won't understand the purpose or reason so just be very very careful there you do not want to say how something is supposed to be done nor do you want to make a story about the developer or the team it is about that user about the consumer of the product okay all right so knowing this now knowing this format of the user story let's jump into the rubric that i promised you guys about um so the rubric looks something like this we start out remember i said there's no such thing as a zero point story right there there really shouldn't be there should be some sort of level baseline effort value uh in this particular case just for demonstration purposes i'm giving an initial story point value of two and and i like this it's a nice little rubric to use uh if you guys don't want to use multipliers here i understand that if you're you know if you prefer the fibonacci scale you can certainly do that just know that you know each each one of these dimensions is going to increase the the or jump up a step jump up a level on the fibonacci scale but i do like this multiplier it just makes things a little simpler in terms of understanding so we start out with some sort of initial story point and then for each one of these dimensions remember i mentioned what the dimensions were earlier complexity unknowns and communication so each one of them adds to the story point it actually is a multiplier for the story point in this case but again if you're using fibonacci scale it just means go up a level right whatever so if you're using fibonacci scale maybe your initial story points is one and then if there's complexity so if any one of these dimensions is true then you would increment so you'd go from 1 to 2 to 3 to 5 to 8 to 13 etc but i think the multiplier for me it just works a little bit better so we we have this rubric here that says okay if there's complexity we're gonna have a multiplier of two if there's a set of unknowns then that's a multiplier of two if there's communication things that i have to talk to some other team or somebody outside of our team then that's going to also add to the the difficulty it's another dimension of difficulty to this story so this works out like this so if we have a story that has no complexity no unknowns no communication problems then we just have the initial story pointing of two so just one thing i do want to point out here about each one of these uh about this rubric is that com complexity unknowns and communication in my mind should remain a yes or no true or false bullion um when i've worked with teams in the past on this there has been a question about can we try to put some sort of quantitative value on complexity like you know complexity could be zero to five scale or complexity could be uh you know on the fibonacci scale and we try to evaluate that i really shy away from that because i think it it gets away from the certainty that this rubric really helps to provide and kind of distorts the meaning and purpose i don't like the idea of kind of trying to in a different dimension try to quantify these different uh dimensions of of difficulty but that being said if your team really thinks that it would be valuable to to kind of also expand out on the complexity unknowns and communication issue and and create some sort of value other than true or false on it i certainly understand that but for me and the way that that i present this and the way that i think about it i think it's much better for us to just strictly stick to is it complex or is it not are there unknowns or are there not is there some level of communication with a third party that's required or not and and being that definitive about it i think really helps to solidify and make clear what the intent of this rubric is as well as provide some direction for you that i'm going to be talking about a little bit later okay so going back to we have an initial points if we start out with initial points all stories begin at 2 but there are no for this particular story there's nothing complex there aren't any unknowns that need to be explored and there's no external communication that's required then that means that this story can remain a two now if we add if we say yes it's true that there is some level of complexity to this okay so there's something about this story that is complicated and needs to be resolved uh or it's a it's a complex problem it's a complex solution that we need to implement then that means that it is now four because we we just use the multiplier of two now let's say that there are two of these dimensions that are true so uh maybe it's not a complex problem maybe that maybe the the solution or the ask is not really all that complex and we know that there's not going to be a ton of code but i don't know about that api that we're going to be talking about maybe it's a brand new api that we're implementing um and maybe there's some level of communication that needs to go on between us and some other team or i need to talk or discuss this a little bit further with the customer in order to get some clarity on this and what they're what they're looking for so if there's two or more of these dimensions that are true then we really shouldn't be trying to take on this story it's acceptable to have one dimension of difficulty okay that's that's going to be actually quite common to have at least one dimension of difficulty but once there are two or more of these dimensions you really should be thinking about not doing the story and finding ways to resolve those dimensions of difficulty and i'm going to be talking a little bit about that here in in the upcoming slides about how you resolve each one of these but just know that if you start getting to a point you know where uh two or more of those dimensions are are going to be challenges then you probably shouldn't be doing that story until you resolve those challenges so again if all three of these different dimensions of difficulty exist you really really should not be doing them and i will say that if you find that you have a lot of time you don't have all that many stories you only have the one that you're trying to tackle or a handful that you're trying to tackle um but some of them have these you have two dimensions of difficulty but not all three i can kind of see where you might accept a story that's got two or more dimensions but i really would recommend that you still hold off on doing them and again we'll talk about how to resolve each one of these dimensions and and the challenges presented by them uh up coming up here but just know that i really think it's a good idea to only allow your team and yourselves one dimension of difficulty on a story to be resolved and that's just it okay so uh moving on to complexity so how do we let's say that we have a story that has two or more dimensions of difficulty that have been identified for the story and in order to make it so that that story only has one remaining dimension of difficulty and we can get when we want to get rid of one of those dimensions right we want to resolve one of those problems how do we resolve the problem of complexity how do we eliminate the complexity of the story you can't always do it you can't always eliminate all of the complexity of a story but there are some things that you can do to to definitely eliminate a lot of it so the first thing you need to recognize is that complexity is not strictly an architectural problem architecture can be a part of the problem of complexity but really what we're talking about when we're talking about complexity is the scope of the problem right so it's not about um it's not about the infrastructure it's not about the architecture but it's about the size of the problem itself right what what is what are maybe all the different pieces of architecture that i need to go talk to that's certainly a thing right if i have i really like the rule of three for a lot of things i'm kind of obsessed about the rule of three that if i have to talk to three or i have to write code or talk to three different layers of architecture then that automatically means it's a complex problem but that doesn't necessarily always hold true it's just kind of a good general rule of thumb for me um you guys are welcome to take that but typically if you're talking to a lot of pieces of architecture in order to accomplish the goal then yes it probably is what is the the driving reason why it is a complex problem you're trying to solve however scope and thinking about it in terms of scope goes beyond that idea of just the architecture right you could be writing a single component in react for example that doesn't touch any other layers of architecture and it can still be a very complex problem right maybe everything is handled within that one component but there's a lot of little logic trees that are involved in trying to decide what to do for for certain displays on the screen that have absolutely nothing to do with communicating to other pieces of architecture and that's the thing scope is not just about the different layers of architecture it can be right architecture can be part of it in all the different pieces that you need to reach out to and bring together to solve that problem but really it's about the size of the problem understanding how big of the ask is this how big is the the solution that needs to be implemented to resolve this thing and that may or may not touch on architecture so complexity saying that a story is complex really is an indication that the scope is too large right it's too big and it needs to be broken down into smaller stories so this one big story needs to be broken down into smaller stories that's what complexity really at its heart truly means and there are ways that we can look for seams uh within within those stories that one big giant story there are typically some areas within that story that we can find to break that story open into other stories right one one or more other stories that are really a part of this story that we originally wrote so uh those edges can be the steps in the use case workflow and we'll talk about the use case workflow in just a moment and look at those steps but you can identify some of those themes based upon the steps that you expect the user to take going through the program you can also um if you are writing if you have a story and you're trying to write what's called acceptance criteria we'll talk again about acceptance criteria here in just a moment but if you end up writing a bunch of acceptance criteria for that one story um that typically means that those different acceptance criteria could actually be could could actually be rewritten as new stories so we'll talk about that in a little bit and then also if you are writing an acceptance criteria that has a lot of the words and or or if in them typically that means that the the acceptance criteria should be broken out into other acceptance criteria and thusly could also be broken out into other user stories so if you find yourself writing acceptance criteria with a lot of ands ors or ifs then that means that you're probably trying to encompass too much you're trying to to add too much to this one acceptance criteria instead of thinking about breaking it apart into smaller pieces so uh thus three different seams we're going to identify and look at each one of these here individually now um so the first one was about use cases right and looking at and just to just go back here we're looking for edges in a story we're looking for edges somewhere along this this understanding and comprehension of of the work being asked of us and one of those ways that we can look for places to split off the story into other stories is by looking at the steps that are articulated in a use case so these are use case workflows they look something like this they're just kind of a idea of what the user will be doing like what are the specific steps and things along the way that a user is going to do or encounter as they go through the system to do something right so in this case a very simple and common example is you know the user wants to log in right they want to log into the system so what are this what are they going to do how are they going to interact with the system well the first thing is they're going to navigate to the home page right they're just going to the the main page they're just gonna navigate to it then they're gonna click on some sort of button or link or something that's gonna take them to the login page where they will then enter in their credentials once they've entered in their credentials they'll click on the submit button and when they click on the submit button if everything is okay then they will be redirected to their account page so that would be their login use case if i want to log in as a user and be redirected to my account these are the sequence of steps that i will have to go through in order for me to accomplish that that goal well if we look at this there's one particular step along the way that this whole decision tree can really break apart and be broken into other areas and that's this clicking of the submit button because we kind of took this perspective initially when thinking about this use case and only took the happy path but what if at the point where the user clicks on the submit button there's the sad path what if they've entered in bad credentials what if they've attempted too many times right then what do we do so it's not always about being automatically redirected to the account to the account page there are other ways that we can kind of fork off from this clicking of the submit button so the uh the workflow might look something like this instead so again the user navigates to forward slash they click on the login button they enter in their credentials and when they click on the submit button if everything is fine they will be redirected to the account page right we've already got we've already established that part of the workflow but there's also the possibility that the credentials that they've entered are bad right it's the wrong username it's the wrong password etc and so if that's the case then they should be redirected back to the login screen so they can try to attempt another login attempt right and they should probably also receive some sort of error message that tells them what went wrong you may not want to be explicit about this you know you may not want to say your password wasn't the right password and or something like that because hackers can sometimes use that information to brute force their way through things but um you uh you do kind of want to think about presenting some sort of error message on that login page if the user gets redirected so that there's some sort of indication about why the user is back on this page otherwise they might think oh my login worked but why am i back at the login screen so you need to present some error message but um let's talk about too many attempts right what if what if you have a maximum number of five attempts per 30 minutes or five minutes or whatever and so they've they've reached that maximum and so they need to be redirected to a completely different page it may be back to the login page with a different error message but in this case just to kind of make things simple maybe i put some sort of page together that says you know that's called forward slash failed and if they've attempted too many times they get redirected to that page instead so they're not even they're not allowed they don't get presented to log back in again because they really shouldn't even be trying at this stage so that may be the strategy you take now i want you to think about stories and look at each one of these steps and what a user story is is a way of articulating one or more of these steps right a a a user story is a way of articulating one or more of these steps and typically if a story is too large it is trying to have more than one step being articulated right so maybe we try to create a user story that is the login user story right as thomas when uh you know i want to log into the system so that i can look at my account information right that is a story that tries to encompass way more uh way more steps right writing that story as thomas i want to log into the system so that i can look at my account information that encompasses all of the steps that we see on this page and that is way too much we're trying to do too much within that one story but if we break out the steps individually like this and all of the different branches and decision trees that can happen from each of the different pieces of this we'll see that each one of these blocks is actually in and of itself a user story it is so each one of these steps that that clicking on the submit button to get to that point is a user story once uh once they click on the submit button uh being redirected to the account if everything is good that's a different user story um clicking the submit button and entering bad credentials is a different user story clicking especially when we're talking about being redirected to the login versus the error message right those are actually two completely different stories potentially where if the user enters in a bad username and password one story could be about being redirected to the login but another story could be about the error message that's that's created and displayed so you actually have potential here for every one of these steps along the workflow for a completely new user story okay and that's how you can identify areas where maybe you're just trying to write a user story that is encompassing too many of these steps there's too much that you're trying to to catalog in this story in terms of all of the steps that kind of fall under that category of that user story and instead we should be looking individual steps that the user's taking along the way and each one of those steps could potentially be its own story now that doesn't mean that i think you need to have a one-for-one it doesn't mean that every single step along a workflow requires its own story but just know that if you are encountering a story that is too big you should be looking at ways of breaking it apart by looking at the steps in involved in order to accomplish it and that's where you can find the seams within the story to write out some other stories okay hopefully that is clear so we have this uh new set of cr of um sad paths that could potentially be gone through or written up as new stories and that's what we're looking for right we're this breakdown of the happy path and then sad paths themselves can be completely different stories and that helps us kind of break apart that initial story now one other thing that i do kind of want to point out about this before i move on i want you to think back to what that original story was and notice um how much easier and thinner it is now how much we call it vertically slicing stories um this this the original story of i want to log into the system right i want to you know as thomas i want to log into the uh i want to be i want to log into the system or yeah log into the system so that i can look at my account information that story if you have different stories that deal with the sad paths right you have other stories that deal with all the things that could go wrong in that process then this one story that we originally wrote becomes much easier to handle because it's only handling the happy path it's only handling the the correct credentials have been submitted and now we need to redirect them to the account so that once that one workflow that one sequence of steps is much easier to tackle as a story than trying to tackle the entire thing as one story okay all right uh so what are some of the other scenes that we can find aside from just uh you know looking at the workflow and all the different steps especially if um you've been handed a user story and you did not work with a customer to break down those steps and so maybe your product owner or project manager or somebody else is handing you stories and you need to look at them and say well we need to figure out some ways of coming up with other stories but we're not going to go through this workflow process or i don't have time to go through the workflow process what are some of the other things you can look for well we're going to go back to once again here's the initial set of use case steps right log in use case they navigate to the home page click on a login button they enter in their credentials they click on the submit button and they should be redirected to the account page but if there's bad credentials what do you do and if there are too many attempts what do you do so that's the initial setup here what are some of the things that we as developers would do when looking at this story and the sequence of events the sequence of steps that the user wants to take when we're looking at the one action of clicking the submit button we might write out some acceptance criteria that would look like this so given i submit valid credentials when i click the submit button then i should be redirected to the account page so these are the this is what we call the acceptance criteria you'll notice that the format that i'm i'm i've written this in is something called gherkin so if you've never heard of gherkin this is the language it's given when then uh and i'd really like to think about given when then as a replacement for a range act assert so if you've ever done a test writing before if you've ever written tests in programming you've probably heard of a range act assert it's one of the first things that you learn when you're writing tests is this kind of how do you format a test you set up the state of the system initially that's the act then you i'm sorry that's the arrangement you kind of set up all the circumstances the state of the system that's your arranged part your act is the actual thing that the trigger the event that occurs that you're trying to test and then the assertion is the resulting behavior or new state of the system that that's kind of the sequence that you go through set up this initial state of the system do some sort of thing and then make sure that the result of doing that thing is this thing right this new state or this particular behavior and if you think about it in terms like that given when then is the exact same thing just different language right given and arranged are the same thing so given this set of circumstances so a range would be arrange these set of circumstances the when in given when then the when i click the submit button is the act of arrange act assert right so when this thing happens or pretend or act this way or act or do this thing right that's the when so arrange act and then finally assert is then so then an assert are synonymous so then i should be redirected to the account page so the assertion should be that the assertion in a test would be that some sort of trigger to read be redirected to account page would be the result of that action so given when then is really the same thing as a range act assert it's just that you're using a different vocabulary a different language because this is easier for a user or a customer to read right if you try to present a user with arrange act assert and you you gave that to the customer they wouldn't know what you're talking about but if you said given when then given i submit valid credentials when i click the submit button then i should be redirected to the account page that is something that the user could actually read and understand right and that's one of the great things about using the gurken language in order to frame these kind of acceptance criteria is that it's something that the user could actually understand that's why we do it this way so not only that but when we're talking about the acceptance criteria here i do want to point out that acceptance criteria is not user stories right so given when then is not a user story in and of itself it could be translated to a user story but it is not in and of itself the user story okay that's one thing i just really want to make clear here uh is that given when then is the acceptance criteria it is not a user story now the purpose of this of this acceptance criteria is much like the purpose of a test and that's why i really like to to make this comparison or this really they are synonymous they are the same thing and in frameworks like uh cucumber or spec flow this given when then actually is the test so i'm not making this up it's not like just some some comparison that i drew out of my you know out of my you know what it actually is supposed to be a test and it is the definition of done essentially it is when when we can pass this given when then uh test then that means this particular step or this particular story is done it is ready to go it is ready to be shipped so this acceptance criteria is very important because it really helps narrow the focus and define what it is exactly that the behavior of the system should be and this is where we start to jump onto the how so remember how when i was talking about user stories we were avoiding the how we were talking about the who the what and the why but we weren't talking about how here we're starting to kind of get a little bit closer to the how we're starting to get a little bit closer to defining the how of the system and how it should be working exactly these are closer to specifications than the user stories okay but they're still written in a way that again a user a customer could read them and probably would know exactly what you're talking about maybe they don't know exactly the reason or intent or purpose behind the forward slash account page but they can probably get a pretty good idea of that okay so that's enough about acceptance criteria what i kind of want to talk about now is okay looking again at this click submit button and knowing that we have this given i submit valid credentials when i click the submit button then i should be redirected to the account page that is the happy path acceptance criteria right that's one of the pieces that we put in you might write some more about the happy path but that's just one of the happy path acceptance criteria that you would write but when we start to examine the sad path what about if they have bad credentials what if they have too many attempts well then you might write an acceptance criteria that looks like this given i submit a bad username when i click the submit button then i should be redirected to the login page and that should probably sound a little familiar right we kind of came up with that when we were talking about the workflow and the different steps that the user would take this is just a different area where we've identified that branching we've found it instead of looking at the workflow and looking at the steps we've instead been able to identify it while we were thinking about the acceptance criteria around clicking on that submit button so it's just a different area to find the exact same thing that's all that this is it's the same we're still trying to do the same thing we're trying to find the different branches of logic here but we're using a different mechanism to identify it and in this case it's the acceptance criteria so we would write this acceptance criteria that again says given i submit a bad username when i click the submit button then i should be redirected to the login page then we could add some additional acceptance criteria around those sad paths so given i submitted a bad username when i am redirected to the login page then i should see an error message so this is a little different than the one above it i just kind of want to point out there's a difference here even though the trigger or i should say the setup of the state is almost the same in terms of a bad username the action that's occurring is different and the result is different so the first except or this i should say the second acceptance criteria that we have here is given i submit a bad username when i click the submit button then i should be redirected to the login page that's one acceptance criteria but we have a different acceptance criteria that says given i submitted a bad username same setup but when i am redirected to the login page that's a different trigger then i should see an error message and in fact if you look very carefully at the second and the third acceptance criteria on here you'll notice that the the uh the result of the first acceptance criteria the then i should be redirected to the login page is actually the trigger for the next acceptance criteria right when i am redirected to the login page so these two things are kind of they're very very closely tied together but when i'm writing acceptance criteria i'm very careful to do this to make things very singular in terms of the ones and the thens and if if there are multiple results that should occur from one action i want to write them out as separate acceptance criteria and when you do that that really helps with what i'm getting to on my next point here and that is that these acceptance criterias these separate individual acceptance criteria could actually be rewritten as new stories so i kind of mentioned this a little bit before that an acceptance criteria could be rewritten as a new story and just to kind of give you guys an example of this if we take the acceptance criteria given i submit a bad username when i click the submit button then i should be redirected to the login page you could rewrite that as a user story that says as thomas i want to be redirected to the login page after submitting a bad username so that i can try to log in again okay so you can take that acceptance criteria and just kind of frame it back to the purpose and usefulness and value to that particular persona or user right that's all that you're doing is you're taking that acceptance criteria and rewriting it as a story now since you already have the acceptance criteria you just have to move it over to that story so instead of having this acceptance criteria be associated with the clicking of the submit button story instead you can make it about being redirected to the login page right it's a different story that you can associate that same already written acceptance criteria so this is kind of a nice little efficient way of doing this is to even though your story may be very broad you can go through and think about all of the acceptance criteria then write out all the different branched out stories and then just simply move those acceptance criteria under those new stories you wrote okay so it's just kind of a neat little efficient way whichever one that you kind of want to go through i'm an advocate for all of them okay whatever you feel is necessary as long as you're finding ways of splitting those stories okay so that was the second way the second way that you can find the seams within your stories and acceptance criteria of where some other stories probably actually exist so that you can break these big stories down into smaller ones the third and final way is a little bit more in-depth a little bit more complicated but not as it's really not all that hard to identify um it just takes a little bit more thinking in order to do so we're going to go back to again the use case steps we've got the login use case would you know the user would first navigate to the home page click on the login button enter their credentials click on the submit button and then be redirected to the account page um so what would we possibly see i i see with a lot of developers that are trying to write acceptance criteria kind of falling back into the same habit that they originally got into a problem with when writing the story and that is they're trying to encompass too much in one thing they're trying to be comprehensive about their acceptance criteria and include too many variables and factors in that acceptance criteria so you might sometimes see acceptance criteria be written this way so given i provide a username and password and i have not already made three attempts if the username and password are valid when i click the submit button then i should be redirected to the account page so i kind of want to talk real quickly about the setup of this particular acceptance criteria and how it sometimes gets to be created is because of all of the different factors in setting up the state remember i talked about how given when then is really synonymous with arrange act assert and the given or arrange is setting up the state of the system before you test it right setting up all the different pieces in the state of the system ready to go before you activate the trigger that you're actually testing right so when we're thinking about it in terms of that right what are the arrangement what are the different pieces of the system that i need to set up it would make sense that somebody would write a given in this fashion given i provide a username and password and i have not already made three attempts if the username and password are valid right it's like here is the setup of all the different pieces of the system of the state that need to be set up first before the user clicks on the submit button and that is kind of where you you can get acceptance criteria that looks like this but what should actually happen is that it should be broken out into new acceptance criteria that each one of these uses of the word ands ors or ifs really is an indication that you have a different acceptance criteria that's necessary here you need to write out some you need to expand or create multiple instances of acceptance criterias where each one of the ands you kind of break out into new acceptance criteria wherever you see an and or an or or an if then ultimately once you've broken it out into that separate acceptance criteria you can then again use that new acceptance criteria to create stories around each one of those things so you end up getting the exact same set of user stories but all that you've done is you've taken this one big kind of i wouldn't say incorrectly written acceptance criteria you've just found a way you found the seams within this really large and comprehensive acceptance criteria and you found all the seams within it where you can create new acceptance criteria and therefore new stories okay so that's what we're trying to do there we're looking at the at the way that we're using language in the given when then to find those themes that are stated in terms of ands ors and ifs and then you can draw out some new sort of acceptance criteria off of that which then ultimately can result in new stories altogether okay and this kind of goes back to the previous slide where we were talking about that how we have separate you know acceptance criteria okay so those are the three different ways that you can handle finding the seams within the complexity of the user story to find ways of creating new user stories so that the scope of those stories is much smaller and once you've got those stories down into smaller scoped stories they become easier to handle and no longer is complexity a problem of the story right so that that one dimension of difficulty that is complexity is now eliminated because you've broken it out into several smaller stories okay and you've done it based upon those different scenes hopefully all of that makes sense to you if you do have a question about any of that and you'd like some clarification please feel free to drop me a comment in the comment section below this video and i will be happy to answer it okay so the next thing we're going to talk about is handling those unknowns so we were talking about the different dimensions of difficulty right we were saying there's complexity there's unknowns and then there's communication right those are the three different dimensions of difficulty now we're going to talk about the second dimension which is the unknowns how do you handle when there are unknowns about the story so these are things again like uh you know it's a new api i've never seen before i need to go read the documentation uh or it's uh it's a i have to go create the client for this i've never written a client or it's a new framework or library that i've never touched before or you're asking me to learn something about i don't know data analysis or data analytics and i don't know enough about those things um to really be able to comprehend what it is you're looking for here whatever that unknown is that you need to go and explore and learn about it is an unknown it is something that you need to quantify in this story pointing it's it's something that you need to articulate and say there is something about this story that is going to prevent me from accomplishing it in a quick and timely manner and it is something that i need to go explore so how do you handle those unknowns and again this goes back to if you have two or more dimensions of difficulty then you shouldn't be doing the story you should resolve one of those dimensions so if you've decided that one of those dimensions on this story that was making it the story difficult was that there is an unknown about it this is what you can do about it this is what you can do about handling that unknown and quite simply it's about planning a spike okay this is the the simplest solution to this is to just simply plant a spike okay so a spike is essentially uh something that is almost a substitute for the story as it currently sets right so you kind of put it in place of now spikes are zero point stories um and this is where i was talking about before that user story should not be zero pointed except when you are saying it is a spike and i'm going to talk about that here in just a little bit but essentially a spike and i do want to be very clear about something here it is my opinion that a spike should be zero points i am perfectly willing to accept that if you believe that spikes should also have a bare minimum value i am i am okay with that i i am not going to push back too hard on this particular point because it's not really particularly all that valuable or important but i do think it makes a bit more sense to have spikes be zero points because there is no value to the user in doing them there's value to the developer but there's no inherent value to the user and this just goes back to and i'm going to go all the way back to the original atlassian statement boy this is way back here um all the way back to boy i'm gonna have to okay this right here right this statement by atlassian the focus of story points is to be about shipping value right shipping values keeping the teams focused on shipping value that is the purpose of story points so if you are doing some sort of effort that does not deliver value to the user it seems logical to me that it should not be a story point that is where i think that it's okay to say it zero okay so that kind of goes back to this key point that i was making before about you know there's no such thing as a zero point story except for spikes because spikes are not providing any direct inherent value to the user there's no effort or work actually being done on something that is a direct benefit to the user but again i can be persuaded and i'm gonna have to switch all i'm gonna click all the way back uh but i can definitely be persuaded and if somebody wants to make an argument that uh no no we need to have some sort of baseline value for that because there is an effort in doing a spike i am perfectly acceptable and happy with doing that uh but i would say that it kind of goes back to the okay what what is that default value and how does it relate to the other uh values that you've decided in terms of effort right is it do you re do you reapply the rubric do you try to say this is a complex spike do you say that there are unknowns about this spike well inherently a spike is about unknown so i mean it's going to be obvious it's always going to be at least a two there right or i'm sorry at least a four in that case so are you gonna say that all spikes are four because there's a baseline value of two and then you know because they're all with any spike there's always going to be unknowns or maybe you're saying that um no we already know what it is that i need to learn i just don't know how much of that right that so i could be again persuaded any way that you want to go i just think it's simpler it's easier uh it it helps to again keep the story point focused on delivering value to the user through the efforts of of you know um difficulty of trying to to fix difficulty i think it just is a little bit simpler if we say that story spikes are zero points but again i'm just gonna say this one more time it doesn't really matter all that much to me i can be persuaded to do something else with spikes and story points uh okay so now a story spike should only be written if there is an unknown blocker so the only time that you should really be planning a spike is when there is a user story out there that is being blocked because there is an unknown on it right because there is an unknown that is that is causing one of the uh uh dimensions of difficulty and there's already another dimension of difficulty on it right there has to be two or more dimensions of difficulty and if you've decided well one of the dimension of difficulty we need to resolve for this story is the unknown then that means you can plan a spike for it but if there's no user story i kind of want to be i want to be judicious about how i say this because there are some organizations i totally understand that like all of their all of the work that they do is unknowns right all of the work is about exploring and finding ways and and looking for things to be to to do um looking for ways to provide benefit to the company let's put it that way looking for ways to provide business value in that case you might have a team that's just strictly doing spikes that's all that they do or maybe you plan spikes uh to help kind of do some of that exploration outside of the the typical work that you do for solving bugs or something um i totally get that that may be the s the situation but i would point back to the idea that um if you have a spike planned you should have some sort of purpose or reason or perceived value that you think uh this particular spike relates to if you cannot articulate a value that this would provide to the user why are you doing the effort okay now again this might be simply um an architectural thing i i think this is probably a good example um i want to read more about architecture in in terms of you know maybe you want to again mythical mammoth maybe this is the spike that you're going to do is i'm going to go read about mythical man month i would say that you have to be very careful here and this is where maybe the the organization needs to make a decision or the team needs to make a decision is that really okay for you to be on company time reading about things that are not providing any value to either the business or the user if that's the case that's probably not the right environment or time now it may very well be maybe your organization says hey everybody gets an hour or two every day to go do this or an hour or two every week to go do this kind of spiking exploration but we're going to track it as a spike that's entirely possible that it's done that way but i want to be clear that if there really should be some association of this spike this exploration of the unknown it really should be pointing back to a story that does provide value to the user so even though this effort of exploring does not provide any direct inherent value to the user that doesn't mean it isn't associated to a value to the user okay there's a little bit of a distinction maybe distinction without a difference for some people but i think it is an important thing to do just at least to keep things categorized and simplified so the original story so what happens is when you plan a spike essentially the original story that has the blocker the unknown blocker that story should get pushed back to the next iteration so that during this iteration that spike can be done right that exploration of the problem that looking into a reading of the documentation for the api or the the testing out and building of a client to the api or whatever that unknown is can be explored freely in this iteration without the pressure of trying to get the spike and the story done in the iteration right and the story may be continuously moved back maybe the story because it is zero points this is another good reason why i like spikes to be zero pointed is because um they could be carried over they are kind of an infinite right zero is kind of an infinite number which means it can be carried over to the next iteration if that spike hasn't been resolved yet and if you if you move the spike over to the next iteration that means that the original story also gets moved to the next next iteration right the iteration after so spikes really kind of replace the story in the current iteration and then the original story gets moved to the next iteration and that continues to happen until the spike has been completed until the spike is resolved now spikes are as opposed to story to user stories spikes are actually written for the developer so this is kind of the opposite this is this is when it is okay to write a story for the developer so we would say something like as a developer i want to do this thing so that i can provide this value right so what is it's again it's the same thing as a user story in terms of how it is written it's who wants this what is it they're going to do and why is it valuable it still follows that same format who what and why but now instead of the who being a user it's not a user story it's a spike and a spike is for the developer so as a developer you could say as steve or as charlie or whoever the developer is on the team as a developer i want to do this thing which whichever the activity is that you're trying to explore so that i can value now here's the thing the value is actually going to be pointing back to the original story right so you would say in a spike as a developer i want to just for example i want to research the pokemon go api so that i can complete the bag as full story so the assumption here is you've got some sort of user story out there that is called the bag is full story and you can't accomplish it because you've never worked with the pokemon go api before so you need to go research the pokemon go api before you can complete the bag as full story so what you're doing is you're writing a spike in the same format as a user story but it's oriented towards a developer but the value that's being provided by doing this spike points back to the original story that needs to be done and this really is easily handled in systems like jira or github projects or something like that where you can actually associate this spike back to the original story so it makes it very easy to track and it makes total sense because of course you're doing this spike to provide value for that other story right that's how you're kind of tracking the value and the reason and purpose behind doing this and again this is helping to articulate to whoever is reading this story the reason why you are doing the spike okay as a developer i want to research the pokemon go api so that i can complete the bag as full story right so this if i was just a manager a product owner or a project manager looking at this story i understand why you are not currently writing any code you're investigating you're researching you're looking into something so that you can do this other story that does need to be done and that provides some context of why it is that you're doing the thing that you're doing what is the effort that you are doing undergoing right now to resolve this unknown and how it relates to another story and that story is providing explicit value to the user or to the business right so that is what we're trying to do with a spike is relay why the developer something that is is specifically about the developer in researching and how it relates to the to another story and that other story is providing direct value to the user okay so that's a spike that is how you plan a spike you kind of put together this very similar to user story but the user is actually a developer and the value is always pointing back to the original story that caused the spike to be written okay all right so the last dimension of difficulty um we talked about complexity and we can resolve complexity by breaking stories down into smaller stories and there's different scenes that we can find within those stories to break them down uh then we talked about unknowns and handling those with spikes pretty straightforward pretty easy solution the last one that of the last dimension of difficulty that can be associated with a story is communication right is there's some sort of communication that needs to occur and i wouldn't really necessarily call it issues i know i put on the slide here handling communication issues but it's not really always an issue it may just be a part of how you resolve something or or the work that you have to do but putting communication in as a part of how you are determining the effort involved is something that goes back to again this little handy book i'm really glad i had it on my desk mythical man month there is um a lot of work written in here by frederick um about how communication is a huge part of the work of doing software development okay and it's very rarely quantified i've worked with many many many teams and communication how do you communicate the work being done or what needs to be done or cross-communicating between teams that is something that is very rarely uh thought about when we're trying to write story points it's just not even a part of it again the focus is typically on complexity which is just you know how difficult or i shouldn't say difficult but the complexity of the code right how complex is the code that i'm going to have to write and how complex is the code that i'm going to have to work with that's typically what people think about in terms of complexity or maybe the architecture they have to to work with but that is only one piece of the bigger picture of how much effort a developer has to take in order to accomplish a story and communication is one of those ridiculously overlooked pieces like i i really i don't know too many people that put communication in the forefront of their mind when they're trying to quantify effort it's just kind of this given um out there in the ether resistance to the work that's being done instead of something that's actually quantified as part of the effort to do something and i think that's a mistake i don't think that there should just be this assumption that there's this uh this you know negative pushback on all effort in terms of communication that we should just never really account for just but just assume that it exists that's that's an incorrect approach i think it's very easy to look at a user story and say there are going to be communication pieces and typically these are going to come in two formats there's actually a third that i don't really kind of want to get into but i'm just going to focus on on these two things so there's external communication that is we're talking to somebody that is outside of the organization right it's a customer it's a it's maybe a non-direct user maybe it's a vendor um maybe it's you know a third-party api that we're you know we have to go talk to their customer service in order to get more information um right we could be using another api another parties service and we have to talk to them so that is an external outside of the business outside of our organization and we have to account for that communication right so it's definitely ideal so how do you resolve these these kind of communication issues when you're talking to those other people well face-to-face is always better than phone and phone is always better than email right but to face is bar none the best way to go about it so you kind of have to plan instead of the story you have to plan a meeting right that's that's really all that you're doing is you kind of replace the idea of doing the story with some sort of meeting that has to be happening in this iteration or or maybe you won't be able to get to that meeting until the next iteration but you cannot do the story until after the meeting takes place and i think this is very similar to to spiking a story and that you should only plan on doing this the story after in the iteration after the one that has the meaning in it okay i don't think you should be trying to put the communication the meaning and the story in the same iteration i think that that's a mistake you should be trying to um replace your story with a meeting and then once the meeting is done then you can do the story in the next iteration now if that seems too long so if you're thinking well we're going to have the meeting on on a monday and then our next aeration isn't going to be for another three weeks after that or two weeks after that well that probably means your iterations are too big to begin with and you should probably be thinking about narrowing your iterations to just one week but that's a whole other topic but really you should be trying to essentially replace working on the story with a meeting now i do want to reiterate and emphasize something here that i mentioned earlier i've mentioned throughout this video and that is just because you have a communication does not mean that you don't work the story nor does it automatically mean that you move the story back to the next iteration but if there are two or more dimensions of difficulty then you do definitely you definitely have to move that story back to the next iteration until one or more of those dimensions are resolved okay so if i have a story that has two dimensions of difficulty on it that i've identified one of them is communication that needs to be had with the customer then in that case i would delay working the story until the next iteration and plan a meeting during this iteration right it's it's that simple if i run into a user story that has no unknowns on it it has zero complexity to it but i do need to communicate with somebody i need to kind of get some information from that third party vendor or something but it's not really unknown it's not really complex like it's pretty well known um what it is that needs to be done i know exactly what i need to ask for and and there's really it's not a complex ask that i'm being asked for it's very narrowly scoped thing but i do need to make that communication to some other party well you could still have that story being worked in this current iteration because as soon as you resolve that you can pick up the story right then and there and then it essentially becomes just the baseline effort right and you've resolved that you've made it you've turned that story from a four into a two as soon as you have the meeting right so that's why it's okay to have a four-point story in my rubric a four-point story it's okay to have at least just just one dimension of difficulty but once you have two then that really kind of becomes problematic and it makes it very difficult because now let's take the idea that you have a user story that has unknowns and communication issues on it should you be trying to do that in this current iteration probably not because that means you have you have a spike to plan to go learn through and you have to set up a meeting with somebody are you going to be able to get all of that done and the work that's necessary done in this one iteration probably not right it's that's really not good planning could you put the spike in this iteration and move the story with still communication issues to the next iteration uh yeah you could definitely do that and just make sure you get the spike done before you actually try working on the story that's what you have to do it's a way of managing the challenges that are involved with the story that's all that you're doing with these with this rubric of identifying the dimensions of difficulty and then when you have a story that has a baseline value of something and then you're allowed to have one dimension of difficulty that just means all your stories are going to be really small they're going to be easy to manage they're going to be easy to work and identify and then also you're going to be able to identify and look at all the challenges that are associated with them and then be able to to resolve each one of those things going through through this process okay so going back to um going back to having external communication that needs to occur for the story to be completed again you want a face-to-face meeting that is the best way to go about it if you can't do that i understand a phone or even when i say face-to-face meeting by the way it can be i am okay with video calls video conference calls if you are familiar with them right if if you and the other party are are do a lot of face-to-face communication um then it's perfectly fine to do that instead of in person in my opinion i think they're about equal but if you can't do that and you only have phone okay that's that's fine but it's better to have face to face but really email should be a last last last last last resort in this communication it's just really email's okay for asynchronous talk and kind of documenting things but email is a really bad way of trying to work through a user story right use relying upon an email to be responded to so that you can continue working on a story that is a very bad strategy you should be trying you should be avoiding that at all costs uh so plan a meeting with the stakeholder typically preferably face to face if not maybe you can do it by phone uh i do want to mention here a domain driven development or domain driven design um it is a uh yeah domain driven design is really the right term um what you're trying to do with domain driven design is you want to map out the domain objects so this is just helping i just kind of want to talk about if you're dealing with a customer right and you're dealing with a what we call a domain expert that's somebody that is in the industry that you're that your product is for and you're you're talking to them you're working with them to try to figure out okay what are the different uh things what are the different problems that they are trying to solve and how your software helps to solve those things you you do this thing where you basically map out the domain objects which are the different um the you try to ascribe to uh the pieces of the software that you are writing you're trying to associate them with things that are actually known by them so you create these kind of software development objects like like think about it in a software development object that represents an abstraction of actual piece of work that they do um and you can have you know state and behavior around those objects i'm not going to get into doing driven design here in any sort of depth or detail but it is worth looking into if you're trying to figure out ways to better communicate with your with your external stakeholders you know your your domain experts the people that you're trying to work with that are the customers you're trying to service um understanding ddd and how to map out those domain objects as well as creating some sort of ubiqui ubiquitous language so that uh everybody that you are working with has some sort of common language that you're all using really helps to fix some of those communication issues and understand credent understanding between what the customer wants and what you guys are going to deliver on your team so those are just some strategies some things to think about when you're having and planning those meetings is think about perhaps learning about domain driven design mapping out the domain objects and creating a ubiquitous language for everybody uh to understand and have an agreement upon uh one of the other things i i really like to talk about is there's this this inception process where you define some goals you define some non-goals you identify some personas and then we go through those steps of a use case right those steps of a use case workflow if you can get some clarity on those things that's what you're really trying to get in those meetings is the the goals that they're trying to accomplish the non-goals that they don't really care about who are the types of people that this software is for or this user story is for and then um you know if you don't know who that person is like for example if if your user stories keep coming to you in terms of a role like as a user as an anonymous person uh as a clerical worker as an administrator if that's how if those are the personas that you are getting you need to go back to the customer and say who are we actually writing this for it doesn't have to be specific names but just give me an idea of the actual people that i'm writing this for not just some not just uh you know some person based upon their job title or their role within the organization i want to know who who are we writing this for what are the characteristics of that of those people and i like to break personas down into uh roles uh goals and uh potholes i call them rolls goals and potholes for personas what are the roles that they have within the organization what are the goals that that particular person has in their interaction with the software and potholes are what are the things that we need to know about these type of people that so that we avoid any sort of trouble when we're writing these things okay so roles goals and bottles might do another video on that all together about writing personas but um just know that these are the types of things you're trying to get clarity on when you're working with a uh with a stakeholder with somebody that's external and then also on the flip side if your external communication is to a third-party vendor then you and that person's role kind of flip here so you are trying to convey to them what your goals are you're trying to convey to them what your non-goals are you're trying to convey to them what your personas are you're trying to convey to them what your work use case workflows are right so the direction is just simply reversed so you have in you have uh you know clients that are trying to communicate to your system but then if you're trying to talk to some sort of vendor then you essentially are the customer and you're still trying to get the same things it's just that now you're on the other side of it right okay so that's if the communication that needs to occur for a story is happening with some sort of external person right some sort of external organization or company or person that is not within your company not within your business you can't just go walk over to that person or get them on the phone uh and you know they're not a part of the organizational team that you're working with and and i don't just mean the team yourself but i mean the actual entire business the entire company um you know actually you know i should say that that external could be an internal person like if they are um if they are your customer right so if they are uh i guess external would be more or less anybody who is outside of the development organization so maybe it's somebody from accounting or somebody from sales that's entirely possible they're still kind of external to the software application but they are essentially your customer even though they are part of the organization but you still follow the same rules right you still follow the same plan but the next category that i want to talk about is inter-team this is where i was mentioning before what if you have some sort of requirement to go talk to or present specifications to another team to complete so maybe your team is just working strictly on the front end piece and then there's a back end team or maybe there's a dba team or you know some sort of special handler of a different piece of the domain maybe you've got a microservice system in in place at your organization and you know a group that's handling another piece of the domain uh and and you need to kind of hand off some of the work or you need to communicate with them or you need to talk to them in order to find out information from them about how to integrate your piece with theirs so that's the inter team now when this happens when you have to have this kind of communication you really should try to avoid asynchronous communication okay the this kind of um non-real time this kind of back and forth things that we would do and you know common systems that we we find like slack microsoft teams using email even a kanban board or jira right sometimes that's how we try to communicate even though these are tools to help us plan our our uh the order of work that we're doing what sometimes can happen is that we would write up a ticket say in jira and then we would add a comment and then we would hope that that other person read the jira ticket right and then they add their comments that is not an effective way to have inter-team communication neither is email neither is relying upon looking at each other's kanban board or whatever or burn down charts or whatever you're looking at like that is not a good strategy in terms of trying to resolve stories now don't get me wrong here i'm being very explicit here that i'm talking about resolving user stories that doesn't mean these are not good tools it's just that they should have a completely different purpose right they should be purposed for other things that typically i like in terms of documentation or coordination of efforts but or coordination of of maybe what's in the backlog but not in terms of i'm working a story and firing off an email to the other team and waiting for them to respond back that is a very bad strategy and slack even though it's a little bit more real-time same with teams that doesn't really make it any better because you don't know when you're going to hear back exactly uh so and then of course jira tickets again just because you leave a comment on a juror ticket and you ask somebody to comment back that doesn't mean that there's going to be really good communication and and again there is a place for asynchronous comms but it is not in solving these stories it's not about you know you can have these tools they're great they're great for communication and inter-team cooperation but when you're actually trying to solve a story and write the code or or fix an issue or communicate about an issue you don't want to be doing it via this these asynchronous communications you instead want to be doing something real time you want to be working hand in hand with that person as much as possible or with that team as much as possible maybe both of your teams will mob together like that's entirely possible either you can pair program you can you know you can swap people on teams or you can ask that person to come over or one of the people one of the experts over there hey can you spend an hour or two with me working on this problem um or maybe you just mob everything maybe you bring both teams together to do a lot a live session um or maybe you do it in a zoom communication room maybe you're using live share to kind of simultaneously work on the problem very similar to pair programming but you're doing it virtually like you can do all of those things but just make sure that the communication is more real-time not this asynchronous back and forth kind of um you know leap froggy kind of way you should be trying to simultaneously be looking at the same problem together at the same time so that the context of the issue is known by both of you as you are discussing it and describing it and talking about the solution uh and and what the what this would entail so um that's basically my presentation that's we've talked about um we've talked about what user stories are our story points are for and how they are not a time quotient and instead they should be about the difficulty right you're trying to quantify the difficulty or the effort around resolving these stories they're not about time they should never be about time uh then you have uh the the dimensions of difficulty rubric which allows you to identify and look at each story to determine the challenges of accomplishing that story right so we have it's a complex story which is really the scope right the scope of the story um is complexity so if it's complex we talked about looking at the story and identifying with each one of those uh stories where are some seems within that story that we might be able to extract another story a smaller piece of the puzzle so that the one story that we initially wrote isn't as big it's not trying to tackle as much instead we can break it out into a bunch of smaller stories um so we talked about the different strategies of identifying the seams within the story uh you know within the workflow that generated those stories within the acceptance criteria that's written for the story uh you know either there's multiple acceptance criteria or maybe there's an acceptance criteria that was written with far too many ands ors and ifs and you know kind of this branching logic here in the setup of the state of the of the acceptance criteria we also talked about how acceptance criteria is really just another test it's just another way of writing a test that was pretty good um so we talked about all of those different strategies of resolving the complexity of the story then we moved on to the unknowns right we're talking about how how do you if there's an unknown something that needs to be explored about the story what do you do well you simply plan a spike a spike should be a zero point story i prefer again i can have some pushback on that that's perfectly fine but you have these um spikes that are really software developer stories they're for the developer and they point back to the value of doing that spike is pointing back to some other story you really shouldn't be doing a spike unless you have a story that has an unknown that requires the spike okay otherwise you're not really doing it for anything other than just your own edification and learning which i'm not against i'm certainly not against all i'm saying is that that probably should not be tracked in the system because we're tracking story points in order to determine the effort and track the the work being done for producing some sort of value to the customer and if it's a spike that is just for your own self edification it has nothing to do with any effort that's undergoing for the customer then it probably doesn't need to be tracked it doesn't need to be something that's in the system and also you know there's no such thing as a zero point story other than the spike because the zero point story means why are you even doing it um if there's no effort or there's no difficulty to the problem then anybody can do it it really shouldn't be on the developers to do that thing it should be on somebody else it really should um so we talked about spiking spiking so that and the spike goes in place of the story the story gets shuffled to the next iteration so that the spike can be can be done during this iteration and then finally we talked about communication right and dealing with anybody outside of our team whether that is the customer or a vendor but somebody that is interacting with our system outside of the the boundary of our application and that could be somebody completely external to the company to the organization um but also we have this inter team right so if we're dealing with external people outside of the organization we want to try to plan face-to-face meetings and we kind of put those meetings on the docket instead of the story so we move similar to spikes we move the stories to the next iteration and we plan a meeting during this iteration um and when you're doing those communications with those external parties you're trying to get clarity on the goals the non-goals the personas and the steps that are involved in the work in the use case workflow again if you are taking these requirements from the customer then you're trying to plot out these goals non-goals personas and use case steps but if you are working with a third party api you are expressing to them you're trying to convey to them those same things what are your goals what are your non goals what are your personas and what are your use case steps so that's what you're trying to do okay you're trying to to convey that information back and forth between those external parties if you are dealing with an internal uh if you're dealing with a team that is internal to the organization that you need to work with um try your mightiest to avoid asynchronous communications right we're trying to avoid email we're trying to avoid jira or kanban or slack or any of those communication systems that do not work in real time in tandem with that person or with that that team um again that doesn't mean you never use those tools it just means that those tools are not meant for solving your user stories right they're not they're they shouldn't be used for the work directly related to the story that you're trying to to resolve uh instead you should be trying to do as much as you can try to do real-time communication i realize that this is not always possible okay so don't get me wrong i understand that sometimes that person is only available via email like i cannot i've tried multiple times but they only respond to their email and they don't even respond to their slack they don't respond to jira like they don't they don't they won't work with me they don't they say they don't have time to come work with us i get that that happens but as much as you possibly can try to avoid those situations and make it the normal uh make it the norm that your team will actively bring those people in to work with you through the solution okay that needs to be a matter of course like that is the way that you guys do your business that is the way you conduct yourselves as professionals you bring those people in to work with you on those problems you don't just rely upon that asynchronous communication of slack and email because it it may be easier in some cases it may seem simpler but it means that there's going to be a longer delay in getting the stuff done and also context can be lost right we don't understand things and and it can lead to a long chain of emails a long chain of slack messages back and forth about this that or the other thing that doesn't it just it's external communication that's not necessary where if you just worked together and looked at the problem together at the same time the solution would snap right into place and you guys could go moving on about your day so that's that's basically it i hope you guys enjoyed this um this is a a this is very similar to how i do uh tdd my tdd lesson for react this is an actual lecture that i would produce in the classroom um this is so hopefully if you are if you guys are working for organizations that you're looking to to build better agile systems you're trying to to build your teams up um feel free to reach out to me because i can get you in contact with galvanize the the company that i work for we do this for a variety of different companies and large enterprise organizations um so this is something that i do all the time the same kind of content that i deliver and if you're looking for really good useful help and and coaching and learning um in the classroom if you want agile education extreme programming education scrum education we can do all of those things but we also of course train on some of the basics like you know if you have a team that wants to learn about.net or or about java or spring or spring cloud or microservices or kubernetes or docker or you know or aws or azure like you name it you name what it is that your organization is looking to learn about and we have a program that we can either either we already have an existing program for it or we can easily create the the curriculum for it we have a very large staff of professional individuals um that that can definitely put together the curriculum and do the delivery so if you're looking for any sort of help within your organization on any of these things please feel free to reach out to me and i will make sure that you get in contact with the right person so you can have quality content just like this delivered in the classroom in person with the team is coaching them working through all of these problems and kind of continuously correcting them that's what i do on a daily basis that's my job and i absolutely love it i hope you guys get that i i love talking about this stuff i know there are a lot of slides in this in this particular one because we're dealing with a lot of abstract concepts but i think that i've given you guys hopefully enough uh really good useful helpful information and strategies to tackle the dimensions of difficulty and understanding that rubric right knowing what the dimensions of difficulty are and how you can you know what are the strategies you can use in order to to fix each one of those things i especially think that the big one is handling complexity right how do you rewrite stories how do you find the seams within the stories to make smaller stories and be better apt at quantifying the effort and work that the teams are doing anyway if you guys did like this video please hit the thumbs up button and make sure you you like it and favorite subscribe it all that good stuff i appreciate it when you guys do it's a big help when you guys do all that stuff so i i appreciate the engagement again if you guys have any questions on any of this please feel free to drop me a comment in the comment section below and if you are interested in any of those kind of services like i talk about that we deliver for galvanize feel free to reach out to me and i will make sure you get in contact with the right person so thank you so much everybody i hope you guys have a wonderful rest of your day bye [Music] you

Channel: Programming Made EZ

Views: 1,097

Rating: 5 out of 5

Keywords: agile, user stories, story points, story pointing, agile estimation, story point estimation, agile development, story points estimation, story points vs hours, agile estimation techniques, define agile anatoly, story point, agile training, agile software development, agile estimating, agile estimating and planning, user stories in agile, user stories and use cases, user stories vs requirements, agile story point estimation example, agile methodology, user story estimation

Id: sYxVnptVK6s

Length: 108min 12sec (6492 seconds)

Published: Sat Nov 07 2020