 I'm Geoff Watts and welcome to another of my top 10 tips videos. This video is about avoiding carryover. So this video is in response to the comment on my previous top 10 tips videos about distributed teams from Master Carpenter. Master Carpenter had a number of challenges that he was facing. This did a number of symptoms in the comments field and we worked together to figure out that overall what he really wanted some information and help on was how to avoid carryover at the end of a sprint. So as I said when people like subscribe and comment there's a good chance that I'll pick your topic for a new video. So if you're interested in something you want some top 10 tips about then just like this video subscribe to my channel and add something into the comments and who knows next time we could be looking at your challenges your topics. So first of all what is carryover? Well most agile teams work in iterations and so at the start of that few weeks sometimes two weeks three weeks four weeks they will try and work out of all the things that they could be doing perhaps it's a product back a lot perhaps it's a set of user stories what do they think they're capable of delivering within that iteration so they'll work with each other they'll work with the product owner find out what's involved look at what skills they've got and then estimate these items and try and work out you know what what they're capable of what their capacity is and then for that iteration they'll give it their best shot they'll work on things and then at the end they'll see what they actually manage to deliver review and use that information to plan the next sprint. Sometimes however they don't manage to deliver everything they plan to and these items often get carried over into the next sprint hence the term carryover and why is that a problem? Well there are a few reasons why it could be an issue for us and I'll just pick out a few of them usually it's not a nice feeling to not to complete everything as human beings we like to actually get a sense of closure on the work that we're doing and if it's carried over then it's just sort of hanging around it's not a clean end of the sprint for the people actually doing the work but also the stakeholders who are delivering for morale can drop and it can easily become the habit that we get into it's just something that happens you know I work with quite a few teams that will plan for this amount of work knowing that they're probably only going to get this amount of work and it just becomes the way that we do things and it's not particularly inspirational it's not particularly fun but apart from that it's actually not great quality wise if we've got half done work hanging around then it's quite difficult to actually close something out and deliver a potentially deployable increment with confidence that it's going to actually work half done work often leads to technical debt and that causes support issues which then makes it harder to commit to things because we've got an unknown amount of support work and bugs that we need to fix and it can become a vicious cycle sometimes teams will respond to this situation by saying well let's just have a longer sprint if we're struggling to fit things into two weeks and we've always got things hanging around let's have three weeks and then we've got more chance of delivering within that time frame sounds kind of logical but really what I found is that actually teams then take on a bit more work and then struggle to fit things into three weeks we talk about Parkinson's law where the amount of time required to do something expands to fill the amount of time available and if we're not getting into a habit of completing things we're not going to complete things in three weeks that reduces our agility it reduces our ability to deliver early it reduces our ability to get feedback early so longer sprints generally are not the answer even though it can feel logical to just give ourselves a little bit more time if we're operating in an environment where perhaps we're trying to build up some confidence in the idea that agile approaches a good way of working then having carry over at the end of the sprint generally doesn't increase that level of confidence or trust in the team it's much better to deliver a small amount of work and get it done than have a bigger chunk of work not done in terms of confidence in terms of morale in terms of predictability so there are a number of reasons why having carry over isn't a great idea but what can we do about it that's where we go next so my top 10 tips for avoiding carry over at the end of a sprint at 10 have shorter sprints that's right i said shorter even though we just said don't have longer sprints actually go the other way if you're working in two-week sprints and you're struggling to get things finished in two weeks have one-week sprints it's a bit of a challenge one-week sprints are quite tough but the principle behind it is you will have to take on less stuff your product owner will have to break things down into smaller chunks therefore you increase your chance of getting something done the smaller the time window that we're trying to estimate something in the less range there is of us being wrong so if we're 10% wrong of two weeks worth of work that's twice as much out as if we're 10% wrong in one week's worth of work it's easier to estimate easier to plan easier to commit and easier to get things done tip nine use yesterday's weather so i was told this story a while ago and i've no idea whether it was true but it illustrates a point so i was told that one company spent a lot of time and a lot of money trying to predict the weather and they were pretty successful they found that about 75% of the time this machine could use the variables that was input and accurately predict what the weather was going to be like the next day and so the people who built the machine were pretty happy after they'd used that machine for quite a while they found that actually if they just looked at what the weather was like today it was 75 likely to be the same tomorrow so just by using yesterday's weather as a predictor of tomorrow's was exactly the same accuracy as this really complex really expensive machine that they built how's that applicable to agile teams we're not in the business of predicting weather but we are in the business of predicting our capacity and what we're saying there is the best predictor of future velocity what the team can do in the next sprint is what they actually did in this sprint so if we've got some data saying that the team only managed to complete 90% of what they what they commit to yesterday's weather rule would suggest that you only commit to 90% of what you did commit to last time just commit to what you're actually capable of getting delivered why wouldn't teams do that anyway various reasons but they'll convince themselves that actually this sprint's going to be different we're going to get better at predicting things maybe we are but until we are go with the data that we've got tip eight now this might sound like a controversial one feel guilty I think every team should feel a certain amount of guilt if they don't manage to deliver what they said they were going to deliver in that sprint internal guilt guilt themselves not necessarily to anybody else but a sense of I feel a bit bad that I didn't manage to do that because if we feel bad about it then we're incentivized to do something about it maybe it's a case of having a minute silence for the stories that fell during this sprint the work managed to be completed actually spend a bit of time and effort thinking that wasn't ideal let's do it better tip seven is reduce the work in process for the sprint similar to the tip about using yesterday's weather if we're in the habit of taking on eight stories or eight product backlog items or eight requirements into the sprint take four just take four plan for four get four done now hopefully we'll still have some time left in the sprint when we've done half of all we thought we were capable of we can still bring those other four in if we need to bring them in when there's time left maybe one at a time it's much easier to focus on getting things done if we have less things to focus on maybe we go really extreme and try and operate on this principle of single piece flow one thing bring it in get it done move on to the next tip six is reducing work in process for each individual skill area so not just bring less stuff into the sprint but make sure that we're not overloading one particular part of the development process or one particular skill area if we're mapping out our flow of work through the sprint perhaps we need to do some design during the sprint we need to do some analysis during the sprint we need to do some front end works and back end works and testing some verification make sure that none of those stages is overloaded with too much work in process at any one point in time so you set buffer limits you set whip limits and say for argument's sake all right when we've got two things that are in the queue for component testing we won't add a third until one of those things has been moved on and we will swarm everybody will gather around those items that are stuck and get them moving forward before we add any more work one of the most common failure patterns from our job team in the early stages of self-organization is that we just focus on getting more and more stuff done individually rather than done at the team level tip five is actually recognize reward and appreciate get a good feeling for things getting done it is a good feeling getting things done imagine you've got a list of to-do items having that item crossed off or ticked off that's a good feeling so maximize that I've worked in teams where they've banged a gong when they finish something when there's a sense of ringing the bell this one's complete almost a mini celebration might feel a bit weird to begin with but just really emphasize that feeling of getting things done because then we'll want to get more things done rather than keep things piling up in the not quite done column thinking about our daily scrum that's the first question what have we done since last time that's the point of it get a sense of progress get a sense of momentum get a sense of yes we've completed something and look around at your teammates when you say yes I've completed this congratulate that person recognize that person appreciate that tip four protect the team from distractions another common reason why teams don't get things completed and have things carry over is because during the sprint something happens that actually distracts them from their commitment their focus is taken away whether that's new requirements coming in or disturbances in the environment anything that's distracting the team or disturbing the team from their focus eliminate it protect the team from those distractions make it clear to everybody else that this team has got some really important stuff that they're focusing on and they need to get it done tip three don't allow undone work to be demonstrated in the sprint review in a similar way to rewarding recognizing and appreciating stuff that's done don't be tempted to give partial credit for partially done work that might seem harsh but if it's not done it's no use don't incentivize partially complete work don't recognize it it's not done doesn't come to the sprint review we don't get credit for it simple tip two help the team want to get things done now I said there's motivating factors to getting things done but it's all well and good me saying that it's only useful if the team actually believed that themselves so it talks to them when was a good feeling during the last sprint when are we at our happiest when do we get those biggest sense of achievement that biggest sense of completion and help them visualize that help them really substantiate within themselves and then ask them would they like to feel more of that if the answer is yes then we can move on to tip one tip one my top tip for helping teams avoid carry over in the sprint is ask the team members themselves what's worked for them in the past when they've wanted to get things done this doesn't have to be work related it can be anything outside of work their chores their habits that they tried to get into anything at all where they've managed to get things done they've got into a habit of getting things done how have they formed that habit and see if they can transfer that learning those habits into the work environment perhaps they like making lists perhaps they like rewarding themselves for getting things completed what works for them and build that into more of the daily routine so that they can get more of that good feeling that i identified in tip two it's all for the team's benefit i can try and force people to get things done or i can make them realize how much they want it and then give them the opportunities to get more of that so that's my top 10 tips a quick recap use shorter sprints use yesterday's weather feel a bit guilty about not getting things done reduce the working process for the sprint reduce the working process for each stage in the sprint and swarm value getting things done protect the team from distractions don't allow undone work to be demonstrated in the sprint review help the team want to get things done and ask each member of the team what's worked for them in the past in getting things done well i hope that video was of use to you especially master carpenter and if any of you out there thinking well i'd like to see some top 10 tips on another particular topic all you need to do is like the video subscribe to the channel and add something in the comments field and we'll see what we can do until next time take care