Scrum Training - Crash Course - 2013-06-18

scrum I'm not sure everyone's experience with scrum is but this this is meant to be just a crash course just to a mental dump of everything that you need to know to essentially you could start from tomorrow it's going to be a lot of information and that's just okay so I wrote a goal down for for me as I was doing this you may have your own goals but just a basic goal as a PSI associate I want to learn about the scrum development methodology so that I can help drive business value and customer satisfaction very basic and there's some criteria to that but I hope that I can help help drive by the end of this you should be able to define some basic scrum terminology it may sound weird but by the end of this you will know the difference between a pig and a chicken also scrum rolls and able to write hopefully an effective user story which is a key to to scrum development and like I said this is a crash course that's going to give you everything that you need to know right now so it may feel like just a massive fire hose and that's completely okay that's the goal of this one hopefully it won't take us the full two hours but we blocked it out just in case you may have fun with that fire hose you may hate it and you may get really mad at me but that's okay just a basic agenda for today we're going to go over kind of the history to scrum where it came from to understand where it came from helps us understand what it is today a basic overview of the iteration the process and then some various facets and and components of scrum being the backlog the planning sessions the daily scrum sprint review retrospective and then key metrics that we have through the scrum process so let's dive right into it with the birth of scrum in order to understand it we've got to understand that scrum is a development methodology just like any other development methodology it has a software development lifecycle this is a very traditional lifecycle various implementations of life cycles have the same phases with different names but overall it's the same order you start out with an idea you go through defining that idea refining the idea planning a schedule gathering all the information you need and then you go in to actually design and implement and build that solution and after it's been built and tested then it gets implemented into the production of the live environment you maintain it over the years and then eventually it fades out in something else X's place right so that's just a very basic development lifecycle one of the most and bring me the most traditional development methodologies is the waterfall methodology which takes the same cycle the same phases but literally puts them in a specific order you first start with initiation and you only do initiation you do that from start to finish once that is done then you then do you only go into the next phase so just like a waterfall there is no going backwards you only go forwards and each step has a defined path define start and end dates and all in all of its glory of a specific path there's benefits to it right because it's so strict it has a lot of discipline it's very simple to implement because it's it's very simple to understand here's the first step when you finish step one you go into step two very easy to implement it's very easy to manage because of that and it's perfect in the world of mass production for instance in order to make a can of coke we know exactly what it takes to make that can and exactly what it takes to make what's in the can we know exactly what the inputs are we know the exact process to turn those inputs into the desired output so waterfall is a great thing if you know exactly what it takes to get exactly what you want but there's also some downfalls with waterfall that that have been found over the years because it is so linear there is no going back which means when you go through the initiation phase you better hope that you found everything you need to know or the requirements phase you better hope that you've gathered all the requirements you will ever need for this project excuse me because it is so rigid in that Lee in its lean your method method of going through each phase each phase is then owned by separate teams there's the development team who obviously owns the development process but in in the traditional sense you're going to have project managers and business analysts who would own those initiation phases they're the ones who would gather all the requirements and they may or may not have any collaboration with the dev team for better or for worse it just may not happen and that's just by definition of those phases each phases by different team and there is no guarantee that each team will collaborate with the other teams who own the phases that go come later in the cycle and again since it is a linear process everything is planned upfront so you may go through your schedule planning phase and say we have two years for this project that's the life of the project and then you spend the next two months or however long defining all of the requirements and you plan everything for the next two years and it has a lot of risks risks with it and because you're planning everything upfront those requirements are very strict and it's hard not impossible to change that scope if a scope if something has to change a year down the road there's a huge change management process in the traditional sense to get the original documents the statement of work the contract you have to get all of those things change because they were created so far in advance which again is a downfall of waterfall itself and because the definition of the waterfall process there's a certain way that these triple constraints were triple constraints is a classic term in project management for time cost and scope three things that every project has to have right and because you're planning everything upfront the scope is clearly defined and it is completely fixed whereas time and cost are flexible because it's far more easy to say oh after six months we actually think we need six more months to do the work so we're going to float the time we're going to extend the life of this project add more money to it and again with that downfall you've got projects that may take ten years longer than the original plan and cost an extra ten million dollars to do it then we originally thought but within waterfall that's theoretically okay even though we don't like to do it Waterfall allows that the results the Standish Group and version one have done some surveys every year called the Kaos survey and through that they have found that 86% of projects are either challenged or failed completely those projects are all waterfall less than 30 percent of projects actually complete the way that they were originally planned and 30 percent of projects are canceled flat out before any any work has actually gone on them so fast forward a few years from the olden days of waterfowl and we have this idea of agile agile is another way of developing a project and as you can see it has the same phases I trimmed it down a little bit but it has the same phases the colors I kept the same so first you have your initiation right you didn't you still need to have your idea and you still need to have some degree of planning but you don't have everything that Waterfall does up front and once your once you've planned enough you go into what we call iterations and each iteration has its own planning designing an analysis phase and then the developers actually design their work they build the work they test the work and theoretically they can also implement it and once that's done we move on to the next iteration which we repeat the same phases for different units of work and we keep going through that cyclical process versus waterfall we keep repeating ourselves we keep replanting readjusting renegotiating as we go and also developing and implementing as we go rather than waiting to the very end now because of that there's a lot of myths with agile one of them being we don't plan at all that is completely not true agile still plans yes there is some complaining but that's okay which we'll go to a little bit later just myths because agile is so different from the traditional world so agile um in its in its raw sense is just an umbrella agile itself envelops lots of different development methodology scrum is just one of the many and there are many implementations of agile that take bits and pieces from all of the different processes and kind of put them together kind of the best of all the worlds but if you want to get to to a gelatins heart you can trace it back to 2001 actually up here at Snowbird here in Salt Lake there are 17 veterans from the development world that gathered together for a room for a retreat of sorts and their whole point was to discuss all of the hardships and headaches that they were having within the traditional world of waterfall and through that through that four days they developed what is now called the agile manifesto which it says we are uncovering better ways of developing software by doing it and helping others do it through this work we have come to value individuals and interactions over processes and tools working software over comprehensive documentation customer collaboration over contract negotiation responding to change over following a plan that is while there is value in the items on the right we value the items on the Left more so what that means is yes we need our processes right you got to have some sort of a process you got to have some sort of tool to help drive those processes and help implement those processes but given the choice we would always choose the individuals and the interaction with those individuals over the process if it came down to it similarly if I gave you the most awesome user manual in the world that would be useless if the software it described didn't do anything so documentation is important but we're not going to spend our time on documentation when we could be delivering business value through the working software and again contracts they're just documents what what really is important with the contract is the customer collaboration over it and then again following a plan versus responding to change we do this every day if you're if you planned a route to take when you're driving sometimes that roads under construction is it more important to sit there and wait for the construction to end so that you can follow your plan or would you rather just follow the detour and get to where you need to go so the plan is important but given the choice we'd rather just respond to change that we know has to happen then to stick to the plan that may be flawed from the beginning now like I said before scrum is a subset of agile and scrum actually dates back before the agile manifesto it came out of a paper developed by these two Japanese gentlemen back in 1986 called the new new product development game and in there they defined a new development methodology or strategy that was inherently flexible and holistic meaning like holistic health it looks at not only the body but also the mind so holistic product development and envelops everything about the process and it works the team works together like to reach a common goal much like a rugby team which is where the word scrum comes from from rugby where if you look at football traditional American football every single person on that field has a specific duty and they do it themselves the team works together but each individual spot has their own specific duty in that in that move up the field whereas rugby the whole team literally moves together if you've ever watched a game you can almost draw two lines and one two parallel lines being the two opposing teams and those lines move up and down the field together completely no one's left behind and no one's too far ahead so it's a more holistic approach within the development again that so that new new development game was sourced out of Japan and that came from the Toyota Production system back in the 30s as me as some of you may be aware that was a very revolutionary change to how cars were made the key term there was just in time inventory meaning there's no value in storing ten thousand car doors if I can only work on five at a time so rather than wasting our time and energy delivering and building this massive inventory not only to build it but also to store it it's a huge cost let's just make what we need right now plan just enough for what we need right now we'll use it right now and then we'll get more when we need it it was very Rick sent but very revolutionary and so agile and scrum development came out of this where we continuously plan we continuously deliver and we only plan enough right now to get the job done and so they're facet of scrum going back to the holistic approach is that the team is cross-functional in the idea in an ideal world we want our developers to be able to develop all of them should be able to do QA and test all of them should be able to define requirements that way no one is specializing in a specific thing all the time because and the power of that is when one person is out on vacation for a week we don't want to lose that entire knowledge or we don't want to have a specific task completely stopped while that person is gone if someone else can do that job as well if the team is truly cross-functional then we can continually moving as an entire team so keys to why agile works there's nine common reasons why agile works one of them the customer is in the driver's seat as I said before traditional waterfall each phase was owned by a specific team and it was a very common analogy where the BAS or the business analysts would define all the requirements it's they would packing up in a grenade they would throw the grenade over the wall at the developers and hope that they got what they wanted and because they had a wall the BA and the customers were never injured by that exploding grenade that would eventually explode so now with agile the cut that walls been removed the customer is in the driver's seat the customer is working with the dev team to drive that business value because we're not planning everything out front we're able to quickly react to the market obviously what works and is needed today will not work and may not be needed at all next year so why plan for a product to be delivered next year today with requirements that we almost can guarantee will be invalid or have to change but time this thing is actually needed so agile we're planning continuously we can easily react agile has a lot more visibility which we'll get into with the metrics there's a lot more information that we can use to track the progress and estimate the future progress of a project agile and scrum were in part created by people from the development world not so much from the project management world and it's an ideal environment for developer my background is a developer I came from that background working on both waterfall and scrum projects team morale goes through the roof with a scrum project versus waterfall any developer who's working on a scrum project and doing it well will almost never go back to waterfall it's just a perfect environment for the developer one of the reasons is the team is self managed the team government's what they do and that gives a lot of power when you have choice over what you do it removes confusion and distraction there's a certain piece of scrum that we'll get into that specifically blocks confusion and distraction from the team so the team can actually do their work like in waterfall we planned everything out front so again you almost had to know the future if you're going to do it right we don't we plan as we go so there's no reason to tell the future anymore because we're planning continuously when things arise which they will always arise those impacts are a lot less the struck disruptive to the project and the team because we've only planned enough and we can get around it easily and then continuous improvement is a key principle that again comes out of the Japanese Toyota Production system as well with these triple constraints the original Iron Triangle is completely flipped upside down so what was fixed before scope is now completely flexible because we're only planning enough right now we have room and the ability to change the scope next week we can change the scope as we need to what we fix instead is the cost in the time so at the traditional waterfall approach the question would have been where the customer would have come to a client or developer and said I want you to build me this and then I want you to tell me how much money it'll cost me and how long it will take that was the traditional approach the new agile approach changes that question to say I have six months and ten million dollars what can you build me in that time and that way it's so much more clear as to what the what the cost and time is going to be and because we're fixing cost and time agile projects very rarely if ever go over budget and over time because we fixed those times they have a deadline and we change the scope to meet that time frame versus changing the timeframe to meet the scope from the same chaos surveys they interview an agile companies 80% of organizations are going agile out of the 2012 survey 60% of the organizations use agile on over half on half or more of their projects and interestingly enough since 2012 the US military is requiring all their contractors to use agile in their approaches that's part of their Dakotan to contract negotiation with the military because it is so much advanced and it's in process for those various reasons again agile versus waterfall as you can see on the left the red line is risk and the blue is the value we plan everything upfront and waterfall and we do all of these phases sorry so there is absolutely no value delivered to the customer until the very end of the process and because of that risk is increasing exponentially every single day the longer it takes the customer to have their value in hand the longer we will not know whether or not what we're giving them is what they want it's a huge risk if you look at a July plan as we go we have iterations as we go we implement as we go so not only are we delivering value sooner we're also delivering more value by the end and since we're delivering value as we go we're reducing risk because we can deliver a working screen of working UI to the client and they can give us feedback and say no that's not what I want or that's great but it can you add this and so when we can readjust and replan so we can add more value sooner and overtime it's just a increased value and thus massive reducing risk so that quick history of every of agile and scrum and whatnot so going into the scrum process I said before agile is an iterative methodology and thus so is scrum with with several different facets that we're going to go into today it has different artifacts the backlog is everything the team's going to do or everything in the product to do those sprint backlog that we've been team does right now and then we have iterations which with instra more two to four weeks and again since we fix the time we don't ever to extend those iterations the iteration is four weeks it will always be four weeks we don't extend it and then at the end of each iteration we should have something that is ready to be released and throughout this process we have ceremonies or these are the meetings from ceremonies that happen one of them is release planning another one is backlog grooming or storytime which again we're going to get into these in depth coming soon sprint planning every day we have a daily scrum meeting where the team answers three questions or discusses three topics at the end of each sprint or iteration we have a demo and review where the team shows off what they've done we have a retrospective which ties into that continuous improvement facet of agile where the team gets to meet and discuss the pros and cons of their current work so the chicken and the pig you may have heard this this story about a chicken and a pig it's used very commonly in scrum to define the roles so the pit the chicken says the pig hey I want to open a restaurant the pig says I don't know what we're going to call it chicken says how about ham and eggs and the pig smart he realizes that the pig would be committed and the chickens only involved the pig has to commit to the effort to give the bacon whereas the chicken can just give some eggs and they're only involved now how does that apply to scrum within scrum we have the scrum team these are the pigs these are the only people in the entire process that are actually committed to doing the work the only ones who actually do the work within the scrum team you have the product owner who is responsible for what the team is building you have a scrum master protects the team who facilitates the process and is the authority on the scrum process and then you have the team members the best of the team and that team could be to be developers could become QA business analysts whomever but that is the scrum team everyone else is a chicken because they are not on the team everyone else is they have their stakeholders they have say in what goes on they can have provide input but since they aren't the ones actively doing the work we can't actually say there they are committed to that work and there's a bonus there's a rooster the rooster is someone who is a chicken but just struts around giving useless uninformed opinions dilbert's boss is a great example of a rooster yes Tyler client I'm unfortunately client execs are chickens I will not say that you guys are roosters but your very least chickens so the scrum team a few components of it and the sweet spot for a scrum team is seven plus or minus two people so for anywhere from five to nine people is a good-sized scrum team anywhere better than that you're getting yourself into trouble I've been on teams that have had three people including myself which was horrible to say the least and I've been on teams that were even bigger than nine and at that point it just gets to money you'd almost rather just split that team in half colocation is a huge part of scrum you don't have to be co-located but there's there is so much more value in being able to see and work next to the people you work with I've had experience with teams where we literally shared the same conference room table for nine months it was cramped it was hot but we got a lot done and we grew as a team completely if you can't dedicate your team to a single product then the team can't fully tap into their potential it's best to have that team fully committed to a single project and not sharing resources across different projects along with that it's not good to be changing the team members every week that team has to have a chance to grow and mature together and so keeping the same team together for a while is nearly invaluable and then similarly as Wickham said before self managing and cross-functional quick overview on the ceremonies release planning it's it's very high-level it's a very high-level roadmap of what's to come what we think we can do release is defined in two different ways I've seen one is as the actual installation of a release and another one's a period of time like a sprint or an iteration the end result of release planning is not a commitment it is still just estimates and then anyone can attend those things pigs or chickens story time is up to the team it's the team's chance to look at what's coming in the future it's they can do it whenever they want or not at all it's completely up to them sprint planning have you said is a planning session at the end at the start of every sprint or in duration the daily scrum is 15 minutes every day for the tire for the entire team I change the touch base the sprint review and the demo happens at the end of every sprint and then the retrospective as well at the end of every sprint key artifacts the program backlog is a high-level list of the work for multiple products doesn't have the details in it we don't need the details in it we just need to know high level what's the plan or what's coming up for these products the product backlog is a similarly as the program but it's for a specific product it has a more detail and it is the single source of truth if it is on the backlog it ain't going to happen the Sprint backlog is a subset of the product backlog and it consists of everything a team is doing right now in the current sprint those backlogs have stories which are descriptions of the unit of work which we will get into at the end of sprint planning you have team objectives which is essentially the work that they commit to do in the coming sprint and it also a definition of done which is what the team creates its kind of their agreement their Constitution if you will of what they consider has to happen for every task before it can be considered done it's a very powerful tool there's also a task board which again it's a very powerful tool it is a visual representation of the work in progress right now it's traditionally on whiteboards or on the walls using post-it notes you can see each post it is a specific task or story and you can track that visually through the multiple phases left to right so that everything on the left is yet to be started everything on the right it should be done and ready to be released so going into detail on the product backlog like I said before it is the single source of truth it contains all of the work if it's not there it's not going to happen if it is there there is no guarantee that it will happen but at least it's on a roadmap so to speak it's aware we're aware of that request that need and it will be prioritized the power of a backlog can come when it's completely visible to everyone and anyone can add to the backlog it's literally just a list of what we would like to have for that product its opportunities it's not commitments again is there's no guarantee that everything on the backlog will ever be implemented it's just a list of things that we think would be cool to have the product owner or the PIO is the one person who manages the backlog anyone can add to it but only the product owner has the authority if you will to prioritize that backlog to say these are the things I want next and it's it's the product owners responsibility to help drive the value that we get out of the work so obviously the things with the highest value get prioritized the highest and the lowest value on the bottom and they may never get done but that's okay Andrew yes a PDM is a product owner within our organization not all the time I know that there's within entrada I know there's difference um but generally speaking the PDM would be the product owner a key so again the backlog is just for planning and tracking purposes it's dynamic because anyone can add to it and one of the other keys about it is it's progressively getting refined so items at the very top of the backlog should be fleshed out in full detail so that the team could work on it today and as you go down the list we get less and less detail because principle of agile we're only going to plan for what we need right now there's no purpose in planning stuff at the bottom of the list because we might never get to it or if we do it'll be years from now or months from now so there's no reason to invest time in that task right now so progressively refined items on the backlog again the backlog is the single source for everything so there's different types of items on their stories which we will look into there's bugs chores which may not add any business value but the team has to do it epics which are really big stories prototypes so various different things on there as well as features and themes and spikes different different terminologies for different things on the backlog now one of the the keys of these lori's or units of work on the backlog is what we call vertical slices of functionality so if you picture a layered cake if you say you want a piece of that cake and I cut you a piece horizontally you're probably going to feel gypped because I did not give you a seven layered cake I gave you a ingredient of the cake a single layer that single layer has no value to you whatsoever if what you want is a layered cake so when we add stuff to the backlog we need to think about them in vertical slices of functionality meaning that unit of work that story for instance needs to contain all of the layers to deliver that functionality it needs to contain a UI if a UI is applicable it needs to contain the backend functionality the code it needs to have database work it may need security it may need you know Sox compliance star veins Oxley all of these things are different layers of that slice and the goal is not to slice horizontally but to slice vertically and we want to get those slices small and thin so that we still have all the components vertically but we have a thin slice of functionality so an example might be you want to be able to enter your home address on a screen or your personal information for instance personal information could be credit cards home address your dog's name whatever right rather than delivering everything up front we could deliver all the functionality for you to be able to enter in your first name you still get a UI they're still back-end there's data base work it's not everything for that entire screen but it is a complete unit of work vertically for a single component of the screen and then we can expand on that later so here's an example if you were told to clean the house what would you do that's very vague it's very hard to do you don't know who's asking you to do it you don't know what the end goal is that may seem obvious but you really don't know you don't know where you should start and you don't know when you're going to be done so we can modify that statement all right my wife wants me to clean the house now I know the context is my wife so now I have an idea of what clean the house means because I know what my wife likes right certain things may be more important to her now if my dad were asking me clean the house different things would be important to him which can change the context of cleaning the house but still that doesn't answer all the questions I don't want to do yet so we can further refine this so my wife wants me to clean the house or someone to clean the house because we have dinner guests well that completely changed it because unless your guests are kind of weird you're probably not going to have dinner guests in your bedrooms so now you know cleaning the house does not include the bedrooms you're probably going to have the living room the kitchen those few things where dinner guests maybe maybe but what you originally thought cleaned the house you're probably picturing the entire building but we've refined that to be a specific subset and we're doing it by answering these questions and obviously we can change that work removing the WHO and the why we can completely change that work again if my dad wants me to clean the house that can change my work if I'm cleaning the house because my parents are coming over or better and better yet my in-laws are coming over for the weekend I may clean the house differently then if dinner guests are coming over so this story so to speak this user story this requirement is very important it helps define the scope of what is actually needed in that unit of work so again changing the subject can change the scope of the work and so can the reason understanding why we need this clean we understand the context and maybe the developer can think of a better way of doing it if he knew the ultimate reason why we needed the house clean so a user story comes in this format it's in a conversational voice as a blank I want blank so that I can blank so as a applicant I want this so that I can do this or as a property manager I want this so that I can do this they both may want the same thing but the different people who want it have different reasons for wanting it and done and thus different functionalities required for each person so here's an example as a game player I want my rocket to move back and forth when I press left and right so that I can avoid asteroids that's very specific it doesn't answer everything but it's very specific now adding that so that I can avoid asteroids what if we gave this to the development team and they said you know we can we can have you avoid asteroids without using left and right arrows if your end goal is to avoid asteroids maybe the unit of work can change to a better solution if the developer is involved with this story or another way of asking - there's no mention of up-and-down arrows do you only want to move left and right to avoid asteroids well the asteroids never be coming directly at you and you might never want to go up and down that's not clearly defined here so maybe the demo Merc can come back and say well maybe up-and-down is a better way to avoid asteroids and then we can change the unit work so maybe the story could be reverted to say as a game player I want my rocket to move so that I can avoid asteroids I don't care how it moves I just want to avoid asteroids and then let the developer figure out a way to do that which again gives power to the developer so a good user story has several components one of them is invest independent negotiable valuable estimable sized appropriately and testable I won't get into everything on this one this this topic could take hours all by itself keys if the team can't estimate its size then it's too big if we can't test it then we can never know when we've ever finished if that piece of vertical layered cake is too big then it's useless to the team so having its size right is is key the other one is the three C's card conversation and confirmation as you saw on this one this user story is written on a three by five card with in scrum it is very common to have three by five cards for your backlog to have them written how the story is there because the reason being is you can only fit so much information on a three by five card and even better it's more common to only write user stories with sharpies or with thick pointed markers because that further reduces the amount of space you have for that story because the end goal is to get that story concise to the point to give everyone enough information right now conversation the user story in and of itself is not a commitment to any work it is a promise for a future conversation to further refine that work and then likewise there's confirmation we need to understand what is required to actually complete that and that comes in the form of acceptance criteria which is typically written on the back of that card so again we could reword this story as a game player I want my rocket to move back and forth or sorry my rocket to move so that I can avoid asteroids the criteria of acceptance could be the rocket moves left when I push the left arrow and the Mach rocket moves right when I push the right arrow or other things that affect right those are the criteria for when this will be accepted and that's the confirmation again with the idea of vertical slices the story includes all of the work required to deliver that story so when the team estimates that story they are thinking I have to analyze this thing the story by itself may not be enough information for me and that's okay so I need to spend some time designing it analyzing it I need to actually build it I need to test it I need to verify it maybe I have to deploy it maybe that's required part of the estimation so the user story itself the effort behind it includes everything Andrew we will get into your question later so keep that keep that in mind and then another heat of stories again with vertical slices you want that vertical slice to be as thin as possible so stories should be small enough to be able to be finished in one or two days and that's because we want to be able to track the progress of the team which will see in the metrics it's it's of no use to anybody to have a user story that lasts the entire length of your sprint because halfway through the sprint when I report saying we're still working on this I can't really say whether we're halfway done or not all I can say is we're still working on it we have been for the last four days and we will be for the next five days maybe right but if I have a story that's one or two days long I can knock that out and ideally my report is okay I started this yesterday I'm going to finish it tomorrow and move on so this this will tie into your question Andrew how can we write better you just orys so taking the same example clean the house that's obviously too big even if we reworded this to understand who and why that's still too big all right but we can decompose that story into five other stories at least clean the first floor clean the basement right all of those together will get you a clean house but even then those are probably too big right so we can decompose that one into even more stories so rather than clean the whole four second floor we can clean each room go room by room those are more consumable more doable but that might again be too big so we can keep going we can vacuum the floor wash the windows we can decompose that work into smaller units of work and again that might be too big for my kids when they see a huge messy room it is just too daunting for them so we break it out okay let's just focus on the Legos right now and do nothing else only do the trainings and do nothing else right so when we start with clean the house we can break that work down into smaller vertical chunks so putting away the Legos all by itself is not a complete layered cake it is not the full clean house however I am doing all of the work needed to put away something or to clean something now decompose we kind of touched on there's various sizes right the the the basic the base item unit of work is a story and those could be user stories I've been talking about which is written in the voice of a user there's also technical stories that the team would write now they need to they need to migrate to a certain kind of database or do something specific to just the team and the spike is a term used for a research task so maybe the team needs to spend some time researching this user story so we'll make a new spike allow them time to research it and then they can move on with the story later big stories or epics big epics or features and you have themes so a theme contains many features a feature contains many epics an epic contains many stories some teams will go even smaller and go to a task level now this is not the task that we know in our task system this is a task which is just sub sub steps to complete that story now as you can probably guess the size of the story is completely variant what someone may think is small enough may not be and in my experience most often the chickens are always wrong because the chickens aren't the ones doing the work so if you think it's small enough unfortunately without the input from the one doing the work you won't know if it's small enough which is not a problem it's okay it's just something to be aware of that the team has to have their chance to say what is good enough for them nan Dre I missed your question but hold on don't we can get to it later so once we have a backlog with stuff on it we have to then prioritize it figure out what's the most important due right now and to me that's there's a there's a lot of discussion we can do here but suffice it to say the most important thing is that we put the highest value first if it's not valuable then what's not waste time doing it right now let's do what's most valuable right now and again that can be its own topic which we'll get into in future weeks with with the continued sessions but right now that's good enough so sprint planning once you have your backlog your team has to actually get together and plan out what they're going to do for their iteration or for the Sprint so a sprint is a regular repeatable work cycle is that iteration originally when scrum and agile started Sprint's were listed at about a month long because it was easy to say there's 12 sprints in a year but over the years the industry has changed and the sweet spot right now amongst most companies is a two-week sprint it can still vary it's based on the company but that's that's most typical anything smaller than a week is just too much of a hassle once we define the length of a sprint we should almost never change it there are very few reasons that are valid as to why we want to change the length of the sprint consistent cadence is important we shouldn't be we should always start and stop our sprints at the same time so that way we know every other Monday is a new sprint or every other Tuesday or Wednesday or whenever that way you don't have to guess about when the 10th sprint will be from now because it's always on the same cadence the scope should not change this one kind of sounds contradictory to agile where scope is flexible right which is true scope is flexible but the team in sprint planning plans their work for the next two weeks and they commit to it when we commit to it one of the things that we everyone else all the chickens one thing that we have to do is let the team work we have to of them a chance to do their work so we shouldn't be changing their scope mid sprint right obviously things happen we have urgent bugs we have big problems that need to be addressed and that's okay we can handle that with our planning but for the most part we should not be changing the scope of the work because that just demoralized the team I've actually had experience where on past teams we've for various reasons forces of nature if you will we ended three or four Sprint's back to back mid sprint and we reach and we change the entire sprint mid sprint and in the end we actually lost a complete month of development time because of those constant changes we got nothing done for a whole month we just lost it and that's because we did not adhere or we were not allowed to adhere to this rule that once the team commits to the work we don't change it at the end of the Sprint our end goal is something that is ready to be shipped ready to be delivered into the live environment now again it's a vertical slice it is not the entire process we're delivering it's just a single subset of the process or the workflow and there's also within scrum no guarantee that it will be released on live at the end of the sprint it is ready to be released so the team can move on but the actual release cycle is completely independent of the team's work cycle so sprint planning it's every Sprint general rule is it's about 90 to 120 minutes per week in the sprint so a two-week sprint has about ideally about a four-hour planning period give or take has two parts it's a the one in the house so the what is where the product owner comes to the team and says this is what I want you to do or what we're going to do next and then the second part of it the product owner and traditional scrum would actually leave the room because again the product owner doesn't really care how it gets done all we care about is that it gets done so the product owner leaves the room to help to not influence the team's decisions and the team then discusses how they're going to get what the product owner wants this is for the pigs just the scrum team chickens can come but only when they're invited because again it could be just white noise that's not going to provide value at that moment it's also a good idea to have other scrum team members from other teams in your sprint planning if there are dependencies that you know need to be addressed rather than making assumptions which are risks let's just get the people who know in our planning meetings and we'll remove that risk and we'll remove the assumption and we'll plan around it so again that first part is the what the scrum master facilitates the product owner presents the next priorities and then sati is the team's time to discuss and ask questions of the product owner it's the team's chance to get whatever they need to understand what they need to do and again those stories that the front-door represents might not be small enough yet and so the team has the freedom at this point to break down those stories and estimate those stories to be consumable for them and then the part to the product owner leaves the scrum master facilitates again the team calculates their capacity they discuss the stories in detail they add stories so they're back long they add stories up until they filled their capacity when they're done the team votes on what how confident they are that what they've committed to can actually be accomplished if the confidence vote is fairly low then we might need to replan Moo some stuff out until the majority of the team is relatively satisfied in making a commitment or a promise that we can make those things happen and then you have stretch goals because things happen maybe we're going to get the work done faster and so we have a list of stretch goals that essentially here's the next things we're going to do if we have time to do them if we don't that's fine we'll dress it next time once we're all done the team basically presents their plan to the product owner the plan the Proctor can then accept it or say you know what if you can't so that the team might say of your top 10 priorities we can only do these first for right now and the Proctor may say okay well given that information maybe I'd rather have us work on number 6 first and so the programmer might want to reprioritize based on the findings and the commitments and that's okay and again we can always change the adjustments can get made for when things happen mid sprint but we're not going to change the scope we're just going to address the disasters the keys of sprint planning like I said before during release planning those are not commitments those are estimates the only commitments in scrum happen after sprint planning everything else is an estimate we can't if there's any dates being thrown around we can't hold the team to those dates because the team did not give those dates and not commit to those dates and it makes sense because we're planning for a single sprint which is only two weeks it's a lot easier for us to know how long it will take to walk from your chair to someone else's desk than it is to say how long it will take me to walk from one building to the next that shorter scope that shorter time period allows for better estimates so at the sprint planning is when commitments happen again everything else is an estimate and only the team can commit no one else can commit anything for the team but the team because they're the ones who do the work everyone else's in the analogy a chicken part of sprint planning you have estimation estimation is completely relative you can use whatever scale you want you can use bucket sizes you can use t-shirt sizes you can use animals you could use superheroes doesn't really matter all that matters is that the scale is understood to everyone now the key with this is all relative estimation looking at that picture of the buckets you really don't know how big that small bucket is that could be a pint it could be a gallon it could be ten gallons you have no idea that doesn't matter all that matters is a small is a little bit smaller than a medium and a medium is a little bit smaller than a large and likewise large is more than extra-large it doesn't matter what what the real size is it's just relative sizes so you estimate relative size versus relative complexity a a very small size task could be very complex right you the effort you estimate the s the effort versus the difficulty the team gives their own estimates it's not safe to ever estimate for the team again the methods not important the scale is not main however ever use it's not important all that matters is that everyone knows the scale and what it means within scrum the most common is story points story pointing is created based on a modified Fibonacci sequence as you can see here it's literally we literally have poker cards a deck of playing cards and those cards literally have those numbers various decks produced by various companies you know may change but the numbers the most part go from 0.5 1 2 3 5 8 13 2014 finiti right it's a modified Fibonacci sequence when we estimate we we estimate using these points and again it's relative how big a one how big it really is a one we don't know doesn't really matter all we need to know is a two is about twice the size of a one it's very typical to find a baseline so the team will look at all their stories and say okay of these ten stories this one is the smallest so we'll say that one's a 1 and then we'll estimate all the other stories relative to the size and complexity of the baseline that's very common as we said during sprint planning you figure out your capacity capacity for me has two parts one part is how much work the team can actually fit into a sprint and that takes you into take in consideration non-working time whether it be extra meetings vacations whatnot and because we know disasters will happen and things will happen mid sprint it's very good and very common to not fill up a hundred percent of capacity you want your team to fill up maybe eighty eighty-five percent capacity and purposely leave extra room so that we can fill in when extra stuff happens and then we don't have to impact our commitments so the first part is how much work can we get done in the sprint the next part is how much of each kind of work can we do in each sprint the important thing is here is is that we can't always work on new development but we also can't push it aside either there's a thing called technical debt which is problems in the code or inefficiencies in the code that you may create right now but it's a debt so you need to go back and pay it later and redo it later you kids can't push it off because if you keep pushing it off you're ending it you're going to end up with a very poor system and likewise you can't push off support you need to address all of these things in your sprint so if here's a good example a very common example the team may only fill up 60% of their time with new work they might spend ten percenter time refactoring their old code 10 or 20 percent could be technical debt 10 percents architecture you might have reserve time for support and whatnot you have to be able to balance the work throughout the sprint so that you don't leave anything behind and then definition have done like we talked about the team creates it it's generic for anything it's not specific to any one task each story has its own specific acceptance criteria that criteria is specific to that one story but every story has common components and those common components make up your definition of done so an example would be we have to have code reviews if it's not code reviewed it's not done if it's not tested it's not done if QA doesn't see it we can't consider it done and likewise the product owner since he owns the project he or she they are the end and say and whether or not the story is acceptable or not so that could be part of definition of done it's again it's completely up to the team to do it and since the Sprint is not directly tied into the release cycle your definition of done may not always include installation an example being one of the one of the companies that make pacemakers they make pacemakers through scrum and likewise John Deere they make their tractors through scrum methodologies obviously they can't deliver half a tractor but they deliver functional pieces of that tractor and then they deliver a hole at the end of the year so their definition of done can't include the release otherwise they'd have nothing done for the entire year so definition of done varies and the team decides it principle of good enough perfect is too expensive no one can afford to be perfect it takes too much time what's more important is it it's functional we don't need to have right now the most amazing user interface maybe we add some buttons here and there that are square and we want them rounded but all that matters is that the button does what's supposed to do so let's get the functionality done now call it good enough and then we can extend on it later we can add more stories and make it better later keep the key point here is gold plating we don't want to waste time adding doing extra work gold plating a task and actuality not add real value so we're not adding any value to the extra time we're spending on those tasks the daily scrum is very quick and simple it's a sum meeting that the team has every day usually at the start of the day but some teams in the industry do it at the end of the day whenever it works best for the team it's often standing up at the task board if a team is co-located standing up is a good method because it ensures everyone is engaged it's very hard to fall asleep when you're standing up so everyone's engaged and everyone answers three questions what did I do to yesterday what will I do today and if I have any impediments one of the roles of the scrum master is to protect the team and to facilitate scrum so if a team member is working on a task and they run into an impediment saying for instance they need help from this other person that other person is out and I don't know who to go to now okay well rather than having that person that team member spend their time finding someone the scrum master can do that and it can help remove that impediment and then through those first two questions we show progress so I worked on this task yesterday I will continue today and I will be done today and then tomorrow if they say oh I didn't finish today I'll finish I didn't finish yesterday I'll finish today that's a red flag is not the Andrew answer it's a red flag because yesterday they thought maybe done so why weren't they done yet was there an impediment that they aren't reporting or is it getting more complicated and we thought um the key here again with time boxing time is time is fixed and we want to keep these meetings to 15-minute time frames if there's any extra questions or conversations that come up which often do during scrum it's more valuable to table those questions and concerns so that we can get through everyone's reports and then when we're all done we can then go back and redress those questions with only the people who need to be involved in a conversation and this scrum meeting is only for the scrum team an extension of this is called scrum of scrums it's very common when we have programs or enterprises or areas that have multiple scrum teams that are interdependent and have cross dependencies it's the same idea as a team scrum it's 15 minutes the representatives are one person from every scrum team typically it's the scrum master but not always the key here is whoever goes needs to be the right person for the job if the right person to speak in this setting is a technical person then that's fine they can be the one to go as long as someone's there every team she represented and then you answer the same questions as the daily scrum what we did but now it's the team what we did yesterday today and our impediments but maybe not in so much detail maybe it's just our team is now working on this feature and our impediment is the database is down right now and we need help with that right the context is a little bit more high-level and it's for everyone in the area to collaborate sprint review what a lot faster than I planned on this is good sprint review happens at the end of every sprint it's a chance for the team to just present what they've done sometimes that's actually functional software sometimes they've been researching stuff and they need to actually document and present their findings and they can walk through new documentation so if your task was to update the user manual you want to be able to present your end result and walk through that user manual now the product owner is a literal member of the scrum team and going back to those benefits of agile where we said the customer presentative is in the driver seat the product owner is the customer representative oftentimes it's best to have a product owner who comes from the customer realm of things so they have that customer mindset but because they're on the team they should be with the team every day and they should know that he's working on every day and so the Sprint review is the official point where the product owner gives the official mark of approval they just go through the motions to check off what's been done but really there should be no surprises here the product owner should know what's been done should I already know what the concerns were there's no surprises it's just going through the motions to make it official is also very good to have the chickens or the extra stake holders at these meetings because well the stake holders are not on the team doing the work they are affected by the work and they're going to want to know what's being done so it's very good to have the these stakeholders at these reviews so that they can see what's been done what the questions are and they can expect they can see what to expect in the next coming release and then the team can also field questions from the chickens from the product or the stakeholders and maybe those questions drive to better development in the future but either way it's very good now similarly with the daily scrum has a higher level scrum of scrums there's also a I must have removed there's a program review the right there it is the same idea as a sprint review but it has all teams participate maybe not everyone from the whole team but at least someone from every team and it's a chance for every team to present to each other what they're doing and this may produce more feedback it may produce more questions it may produce more solutions either way it's a good idea to have but in either case these resume reviews should be a meeting where we celebrate success right the team has accomplished something it's a chance to celebrate make it fun I've had various reviews and I've seen various teams and companies do reviews that they actually bring in food they make it a whole day and they make it a party it's a great time but then we also collect metrics and provide feedback retrospective so going back to the origins of scrum and agile now came out of Japan with the Toyota comes a term cog called Kaizen or Kaizen it's a Japanese word that that means continuous improvement the idea being we are continuously planning we're continuously delivering we should be continuously improving if we don't improve we're just going to get worse over time and the retrospective allows the team the chance to get better it happens at every sprint at the end of it typically after the demo it only contains this the scrum team no exceptions only the scrum team because we want this meeting to be fully transparent and if we have anybody else who's not on the team that could negatively influence the feedback the team gives extreme example you wouldn't want the CEO in your scrum in your retrospective because the team might have some problems with the company and they might not be willing to share those problems if certain people are in those in those meetings so you want to have full transparency and we answer three questions what went well during the Sprint what went wrong during the Sprint and then specific ideas on how we can improve what we can do to improve and in many cases these action items on what to do to improve can actually be added to the backlog they are specific tasks just for the team but they're on the backlog so that the team remembers to do it and then we can actually track its progress if one of the items is the team sits in the same building but we don't sit near each other that could be a problem and what we can do to improve that is see if we can get sit next to each other and so someone might take up that action item to start that discussion about how we can sit next to each other so it's very specific and again very transparent but also it should be fun it's a team-building exercise as well it should be very honest and transparent many teams play games in retrospectives they use this time other than asking the questions answering them to appreciate each other I've seen teams where they spend up you know five minutes writing down thank-you notes on a note card for someone else on the team and it just produces a higher quality team a better morale some teams do team outings for their meetings they still need to answer those those needed questions but they might take the whole afternoon off and just go out as a team it's a chance for the team to grow together and and become more of a team together so now we have some metrics which ties into the transparency and the visibility within scrum that's increased from the traditional methodologies so already we've gone through several things that are very easy to measure we have Sprint's we have specific release time periods we can measure the actual releases through the potentially suitable increments or potentially suitable products we have stories that we commit so we have the number of stories we say we're going to get done and we can track that with how much we actually got done we have stretch goals so after every sprint we commit to 10 stories if we have time we'll do these next five and we can measure that we can measure capacity which is how much room the team has to do the work and we have velocity which we haven't talked about yet but velocity is how much work has been done and can be done so the so when the team commits to a story each story should have story points attached to it already and if we have 10 stories on the sprint and each of those stories are worth two points then we are committing to 20 points worth of work and if by the end of the sprint we have completed all 20 points of work our team velocity now becomes 20 and so when we plan next time our new capacity we know we did 20 points of work last time we will probably do at least 20 points this time so we will plan our capacity based on a 20 point velocity and then as we finish this next sprint our velocity might be 25 and so our average velocity at that point is around 23 and then we complete the next sprint so when we keep doing that we keep a verging on past work to get our current velocity and we use that velocity to to govern and estimate the capacity for future so here's an example of of sprint metrics iteration is the same as a sprint so the the vertical is the different sprints and you can track what the velocity was we planned to do what the velocity was we actually achieved and again we only count the story points of the stories we've actually finished so if we commit to ten story ten stories worth 20 points and we only finish eight stories we've only achieved we've only achieved a subset of our commitment so rather than achieving all 20 points we've only actually achieved 16 points and the Salar our planned velocity was 20 our actual velocity was only 16 likewise tracking how many stories you plan versus how many are accepted or completed you can track quality through all this as well a lot of good metrics and this is just out of a sprint a single sprint so we can have all this information after two weeks and we can expand that so that was a single team we can lift that up to a to a program or multiple teams in this case psi does not mean property solutions it means potentially shippable increment which is essentially a single sprint for all the teams so we have 10 teams every team has a velocity of 20 and so a program velocity is 10 times 20 and we just expand the previous metrics to go across the entire program or all the teams cadence is again a very important thing to keep in mind we plan at specific intervals we release after specific intervals we do retrospectives after specific intervals those intervals don't change if you can picture your cadence as you walk it's or run it's very hard to keep a consistent pace or consistent velocity if you keep changing the distance of your or your cadence if you change the cadence while you run you will almost always fall down this is very hard to keep pace with that so cadence is very important and it's a very valuable metric because if we have the same cadence and we start and stop Sprint's at the same time every time then we will know that in December we will have two sprints and both those Sprint's will start on these dates that's very valuable which will see it in a second why burn down chart is a very valuable metric as you can see it tracks on the vertical attract story points and on the horizontal it tracks the inter iterations and this can even be within a single sprint so the horizontal horizontal would be actually days but either way you track so this team has 500 story points so their backlog as they have estimated it contains a total of 500 points and they have they've estimated 5 Sprint's to complete those 500 points so in an ideal world they would follow this straight line to complete that by the end of the fifth sprint but we have the actual so the plan was to be done with a hundred points after the first iteration unfortunately we only got done about what 75 that's not an answer to a problem it's just a it's just a fact that 75 might be because they were impediments it could be because we had somebody that was sick that week and didn't plan for it so it's not an answer it's just a fact but then as you can see the rate was consistent after that and actually followed the same ideal rate as the plan which is doing pretty dang good so the burndown chart it burns down the story points so that you store with a number and by the end you've burned down to zero now this example is over multiple Sprint's but again this could be within a single sprint so that's day 1 day 2 day 3 which again brings value in having stories that are small so that we can burn down our stories over a couple days if we have huge stories our burn down chart will be flat for a few days and have virtually no visible progress until all of a sudden day four it drops and then we're flat which in the end that may be doable but on day two that provides no value because day two if it was flat we just showed no progress which is not valuable so again those stories need to be small enough to show that progress over time so we have burned down chart we also have burn up charts which is the same idea but reversed so rather than saying in the burn down chart we start with 500 and we have this much left the burn up chart says we have achieved six and we have achieved eight points and we've achieved 31 points we've achieved 41 points fifty forty five and you can track this with business value that's essentially six points of business value delivered and that's 18 points of business value delivered this blue line is the total so here we see for the first five sprints we have a total of 100 story points in the backlog so by the end of the burn up chart your total and your completed should intersect and since the backlog is dynamic it looks like in sprint six we actually added more work to backlog which is totally fine we just added more work we added more estimates and so we have more but we keep adding more value after every sprint so you can track the value add two burn-up chart through tracking that velocity and those three point estimations this one is very valuable I really like this progress report this is meant to be used inside of a sprint if you keep these as stories but really it's good to be at the feature level so as we said before a feature contains multiple epics which contain multiple stories so feature 10 let's say has a hundred stories at this point this is a snapshot for a single day right so at this day featured ten should be 30% completed if it's a hundred stories we should have 30 stories done by this day in actuality we've only got 20 done right similarly feature 9 if it has a hundred stories we should be at 28% completed an actuality we're about 26 that's why each one of these means the colors the top line is the plan the Green Line or yellow line is the actual if it is within 15 percent of the plan so in this case feature 9 yeah we're about 2 percent less than what we thought we could be but that's a very small variance we can accept that whereas feature 10 that's quite a large variance so that one is at risk right now it's not an answer it's just a fact and we need to dive into that to understand why we're so far behind or a feature 4 is even further behind so very valuable again this is a snapshot for a single day so every day or every sprint these numbers are going to change because by the end of the fifth sprint you would expect this to be higher in plan and then the committed or the actual be higher so this one is a living document that increases everyday so tying with this is our predictability measure predictability is a very valuable tool as well and a lot of lot of executives and different and different surveys with agile surveys predictability is more valuable than being on target and being correct with all the estimates you can estimate all you need to at the end if your team is not predictable enough then your estimate your estimate is of no use so here in this example we have a effective control range so this company has said anywhere from 80 percent to a hundred percent is acceptable again perfectionist too is too expensive just because a team does not finish everything every sprint does not mean they have failed completely this company is said as long as we get at least 80% done every sprint then we're okay look at these two teams team b achieved what 95% the first time they dropped unfortunately outside of our range down to about 70 but then they shot back up again to over a hundred and they're back down to 90 so overall they are somewhat predictable there's a lot of variants still but they're at least predictable they will be at least within this range whereas team a they went from 60 down to 35 or 30 shot up to 90 down to 70 they're completely out of there they're out of whack their onyx they're unpredictable and we can't really take anything that that team gives us to heart because we don't know what will actually happen because they're so unpredictable again it's not an answer to a problem it's just a fact and it leads to a future conversation to understand that but we can measure practablity using the committed stories versus axe all stories and story points versus actuals so I know a lot of you guys online Our client execs and you're probably wondering who cares what's the importance about all this so here's an example that we have very often every day so we have a specific story story ABC and we want to know when will story ABC be done well I have a backlog and I can see that story ABC has been prioritized and is currently number 125 in the list and we've already actually estimated it and that's that's five points our team velocity right now is currently 46 points and if we took the value of all the points of items 1 through 124 let's say that is 565 points in the backlog in front of this story so we take 556 points plus the five points for this story is a total number of story points we divide that by our velocity of 46 and we come out with 13 sprints so if nothing changes it'll take about 13 Sprint's for us to get to this story and we already know that our we have the same cadence so Sprint's are always two weeks 13 Sprint's times two weeks per sprint is 26 weeks so based on a consistent cadence our next sprint will start on June 21st we release every Thursday the team is 87% predictable so taking all of that into account I can say that based on the current state of the product I'm 85 87 percent confident that story ABC will be released around or by December 19th that is the release after the end of the 13th sprint so if we had all of those metrics in line today we can easily answer that question what will this be done and I can give you a relative estimate again its estimate not a commitment it won't be committed to until in December when the team actually does sprint planning for that story but relatively speaking I'm fairly confident it'll be around December when we get to that story that's very valuable very valuable information that we can take from all that so that was a lot of information I breezed through that one apologize if there was a lot of information too much information where's anybody have any questions me unmute so anybody online have any questions in aterna yep notice the staple one didn't have before that did you do well so you don't have any questions you can go ok anybody in the room have any questions awesome then so let's go back to our course goal hopefully by the end of this very fast crash course you've gotten some information you can now define some things about scrum you know who pigs are and who chickens are you know who you are you know how to write a user story there's many things you covered more but at least you hopefully hopefully can do that and as extension hopefully now we can understand Dilbert a little better just because we're we don't plan we just plan when we need to and we only plan what we need to just because we're agile doesn't mean we do things faster with fewer people we can change faster just because we're agile and scrum doesn't mean we can do everything all the time we need definitions and those definitions need to be reasonable we need to have stories that are small they're consumable estimable testable we need to have reasonable requirements understanding that we probably can't and won't get to everything but that's ok as long as we're delivering the most valuable things first

Channel: PSInternalTraining

Views: 643,736

Rating: 4.8443699 out of 5

Keywords: training, scrum, development, project management, methodology, agile, psi big deal, psi, property solutions

Id: wNwfFStmtw8

Length: 94min 33sec (5673 seconds)

Published: Wed Jun 19 2013