Lesson 05: Sprint

How do you eat an elephant? One Sprint at a time ;)

00:05.500 – Welcome back, in this lesson we’re going to talk about the sprints.
00:09.500 – Sprint is one of the five events in scrum and it’s a special one because it’s a container for the other four events like every other events, it’s timeboxed and for sprint our timeboxes should not be more than one month.
00:31.500 – In the past, in the beginning the thing that people had in mind about agile was that iterations may not be longer than two months but as we go on people get used to the way adaptive projects work and it seems like shorter sprints, shorter iterations make more sense to most people.
00:55.500 – So in scrum the rule is that they should not be more than one month and obviously there is no minimum for it, it’s up to you.
01:03.500 – the length of your sprint is very important because your sprint is the main feedback loop you remember the adaptive system that we have, you want to check things with your customer and end-user representatives get feedback and use feedback to find your way and most of that not all of that but most of it or the most reliable part of it happens at the end of the sprint where we have the sprint review and we do everything in a structured way.
01:37.500 – So when you have shorter sprints you will have more reviews, at the end of the sprints and more serious feedback so it gives you more opportunities for adaptation but on the other hand it also increases your overhead for each sprint you have to spend some time planning the sprint, some time reviewing, some time having the retrospective and well that’s an extra time so you need to have a balance here, also if your sprints are really short for example two days then you don’t have enough time to develop enough features to show people at the end of your sprint and your sprint reviews will lose their effectiveness so find a good amount based on your products and people involved in the project if your stakeholder stakeholders are too busy, maybe you need to have longer sprints if they are really active and involved in the project maybe you can have shorter ones, can be anything.
02:45.500 – So you decide about it for example, you say that you want to have three weeks’ sprints and then all your sprints will be three weeks, what it means is that we don’t decide about the timeboxed duration of each sprint in the beginning of the sprint That’s not the same in all methods in DSDM for example, you decide about it in the beginning you still timeboxed it, but each time you make a decision but here in scrum to have a simpler system we decide about it once and then use it for all sprints.
03:24.500 – However, it doesn’t mean that you cannot change it at all, let say in one of your sprint retrospectives you start thinking ok we have a really involved customer they’re not worried about spending time with us and our items are small enough we can develop a lot of them and it seems like we need to have more feedback, more structured feedback isn’t it a good idea to have two-week sprints instead of three-week sprint?
03:58.500 – you talked about it as a team all three people; the scrum master, the product owner and developers that’s more than three people, the three roles I wanted to say, actually I censored myself because they’ve change the name role in to something else, we’ll get to that So anyway, all of them together will decide about it and they say that ok from now on starting from the next sprint we are going to have two week sprints, and that’s absolutely fine, it’s great you’re learning from your environment you’re adapting, that’s all purpose it’s a good idea.
04:38.500 – what’s not a good idea is to change it in the middle of the sprint for example, saying that ok seems like we don’t have enough time to finish everything so let’s turn it from a three week sprint to four week sprint or even to a shorter one, that’s not ok, when you start the sprint you want to focus on your sprint backlog, you don’t want to change things like this there is no gain in that, just go on finish your sprint, it’s not too long and then start new things with the new sprint.
05:20.500 – Ok, so the other thing is that some people have some slack between their sprints and they use it to do certain things you probably remember I told you about the product backlog and the changes we’re making to the product backlog in our sprint reviews when you add new items you also need to refined them, you have to add more details to them and it takes some time, some people take a few days between two sprints to refined their backlog or do other things and it is not ok at least according to scrum.org each of sprint comes immediately after the previous sprint there is no time between two sprints in other words, we don’t have anything that happens outside the sprint, everything we do in scrum happens inside sprints, ok.
06:26.500 – some people have special sprints, for example hardening sprint, or integration sprint or something else, these are also, absolutely 100% rejected by most reputable resources, because for example why do you need to have integration sprint?
06:49.500 – aren’t we supposed to have done increments?
06:54.500 – Increments that are absolutely 100% done, so done that if we decide to release them we can release them immediately.
07:03.500 – Now can you really call it done when it’s not integrated?
07:08.500 – or for hardening sprints, it implies that there are somethings that you still have to do for those things, you need to tie up the loose ends or something it means that it’s not done, and you know that it’s not done and that’s the problem.
07:25.500 – Your increments must be done, anything that needs to be done happens inside our typical sprints we have only one type of sprint, just call it sprint all of them are like each other and in each of them you’ll focus on sprint backlog, you create increments and you go on.
07:45.500 – the other thing is about the first sprint.
07:51.500 – Scrum doesn’t talk too much about starting and finishing a project it doesn’t even use a word project so much it’s more thinking about products, tries to be focused on the products practically a project the way we define it is an initiative we use to make changes in to a product or create a product and when I say changes I mean serious changes not minor changes we do in operation.
08:27.500 – So that means that there is no difference between focusing on the project and focusing on creating a product or making serious changes, I’m telling you that because recently there are so many things people who are too excited about a few things they started talking about no estimate and no projects they keep saying that it’s wrong to be focused on projects you must be focused on products well, project is a way of focusing on the product.
09:01.500 – but anyway, in the past in the beginning scrum had some content about the way we start a project and end the project, but right now it doesn’t have that. it’s about the as if we are already in the middle of the project all it has to say about the starting the project is that when we want to start it, we take only a few days create a very simple product backlog it doesn’t have to contain all the items because we know that we are using the adaptive system our product backlog is never complete, we just add a few items and immediately start working on our first sprint.
09:43.500 – However, what some people have is something called sprint zero, in sprint zero they do their preparation their development environment, a few items for the product backlog and so on.
10:03.500 – Scrum org and most other resources, reputable resources, don’t agree with this.
10:11.500 – your first sprint is like every other sprints, and we just call it sprint number one not sprint zero.
10:20.500 – So the question is, what about the preparation? and the answer is which is the answer we always had in agile is that all preparation should be done align with other development work in the first few sprints you will have more preparation to do and less time for actual development but as you go on you will have more and more time for your development but still in the first sprint you will develop something, you will create something that you can show to your customer at the end of the sprint.
10:51.500 – something that is very important here is that if you have one sprint zero focused on preparing then your preparation will be upfront and preparation itself is based on an understanding that we have about the product we’re going to create so if we allow ourselves, to have upfront preparation then we are blocking some of the possible adaptations we are forcing something to our product, but instead of that we want to go on and see what type of product best matches our environment.
11:32.500 – as a result, our preparation should also be on going at least for a few sprints.
11:40.500 – Ok, so there are somethings that stayed a same during the sprints and something that change.
11:50.500 – things that may not change during the sprint one of them is lowering quality, the quality of the product depends on the uses you have for the product we don’t have an ideal quality that we need to try to get close to.
12:10.500 – the proper level of quality depends on how we’re going to use the product, so it is set for each product, for each project separately you know the quality level and during the sprint you may not lower it that’s the almost rule that we have here.
12:30.500 – in your sprint retrospective you can discuss it and if you see that your level of quality is too high for the product it’s not productive, it’s not adding value or something else you can change it and it will be applied to the next sprints.
12:46.500 – and speaking of quality one of the things that’s reflect your decisions about quality the main thing is your definition of done.
12:57.500 – most of the quality related things go to the definition of done the types of test you want to have that’s a quality concern, it’s in your definition of done and many other things your coding standard for example.
13:12.500 – but anyway, the other thing they mention in the scrum guide and applies also to the PSM exam in scrum org is that anything that endangers sprint goal should not happen during the sprint now what does it mean?
13:31.500 – the things that are typically considered as so is for example, changing the composition of the team most people consider it as something that endangers the sprint goal, because it’s very distracting it’s only a two week sprint or three weeks sprint, if you want to change team members in the middle of the sprint then a lot of your potential, a lot of your capacity will be spent on that if you bring a new person for example, you need to tell that person what’s going on in the project and ..
14:07.500 – the best way is to again discuss it in your sprint retrospective and make it effective when you switched for one sprint to the other.
14:19.500 – there’re maybe other things as well, and it’s up to you to decide, if the change that you’re going to make endangers you sprint goal if it does then you shouldn’t make that change in the middle of the sprint, you have to wait for the end of the sprint.
14:38.500 – most things can change during the sprint.
14:43.500 – the most obvious one is the product backlog.
14:46.500 – the product backlog is always changing; we do have sprint reviews where we receive a lot of ideas and make a lot of changes to our product backlog, but that’s not the only time we do that.
15:00.500 – in the middle of the sprint we also have increments, we may show some of them to some of our customers at least we have user acceptance testing and those are done in the middle of the sprint we are received some ideas and some of them may be translated into something that impacts the product backlog which can happen in the middle of the sprint. and that’s ok.
15:24.500 – for the sprint backlog, there is a lot of things here.
15:30.500 – but the sprint goal, we don’t expect people to replace one sprint goal with another sprint goal that would be really weird but you may make some refinements having the same sprint goal but making it more refine although in general you can consider the sprint goal as something that stays the same.
15:57.500 – So that’s one of the things that we have in the sprint backlog.
16:00.500 – the other one, is the items that you’ve brought from the product backlog into the sprint backlog and the last one, do you remember? I mentioned it really quickly in the first lesson I think.
16:11.500 – the work items, these small technical work items that you create by decomposing those items, product backlog items, you can call them tasks.
16:24.500 – So, during the sprint we always add, remove or change those tasks so in that sense sprint backlog is always changing.
16:35.500 – how about the items?
16:38.500 – the old fashion way is to say that as soon as you’re done with the sprint planning you won’t change the items anymore because the developers need to be able to focus on a set of items, if you keep changing that then why do you even need to have a sprint backlog, you can just use the product backlog.
17:01.500 – but gradually during the years they’ve removed that from the scrum guide and also scrum org doesn’t believe in that, so what happen is that you can make every type of change in your items in the sprint backlog.
17:19.500 – well as long as you make sure that it doesn’t endanger the sprint goal.
17:28.500 – but well they want to be really flexible because now a days with some newer approaches to agile development the old fashion way of working that doesn’t seem acceptable to some people.
17:44.500 – so what you need to know is that the product backlog is always changing it can also change in the middle of the sprint and that’s the same for the sprint backlog, it also changes during the sprint and of course a lot of other things change.
18:00.500 – a few other things about the sprint backlog.
18:06.500 – when you approach the end of the sprint some of your items may not be finished.
18:12.500 – one response that is very common, is that people immediately move it from this sprint backlog to the next sprint backlog they consider it the default that if you ‘re not finished with it, you will continue it in the next sprint.
18:30.500 – that is not a good idea, what you have to do is to bring it back to the product backlog then the product owner will order everything again, and if it’s still on top of the product backlog then it will go to the next sprint backlog that’s interesting actually because sometimes you pick this item you start working on it with a certain understanding of it, you think that it will take your couple of days and it will be really interesting for the customer to have this, that’s why it was on top of the product backlog.
19:09.500 – you start working and then you realize that is far from being done in two days, It’s a really complicated thing it requires a lot of changes in many other things you’ve done before and for example, it takes two to three weeks to finish this.
19:27.500 – you’ve done a little bit of work on this, but when you think about it if this item is going to take two to three weeks instead of two days you may not want to have it on top of product backlog anymore, you may have more important things to do first (more valuable things) so when you move it back to the product backlog with the new understanding then the product owner may want to bring it down so you won’t even work on it in the next sprint at least it’s a possibility so you have to be prepare for that. Don’t move it automatically.
20:06.500 – the other thing is that you’re maybe in the middle of the sprint and you’re done with the all items that you have what would you do?
20:15.500 – you just bring another item that’s simple.
20:21.500 – that’s another difference between sprints and other events with other events if you’re done with everything you wanted to do you will just finish them so it is for example, sprint planning meeting and it’s timeboxed for lets say 5 hours after four hours, you’re done with everything you will just finish the meeting, that’s all.
20:45.500 – and that’s the case for all four meetings, four events that are inside the sprint.
20:50.500 – but for the sprint itself, that’s not a case.
20:53.500 – if you’re done sooner, you won’t finish the sprint it’s a fixed duration for sprint and actually it’s a maximum duration for the other events, that’s the difference.
21:06.500 – and the reason we want to fix this is that we want to make it simpler if you decide to have two week sprints then you’re sure that every other week you’re going to start a new sprint it won’t move at all.
21:21.500 – but with smaller events inside the sprint there is no reason to fixed them really, because if you’re done with what you’re supposed to do what else do you want to do?
21:31.500 – here you can do something else you can bring a new item, so that’s how it is.
21:37.500 – Ok. one last thing we the sprint goal and the items in our sprint backlog, and our idea is to achieve the sprint goal by developing those items.
21:58.500 – but sometimes when we start the sprint and we are in the middle of the sprint something happens that proves to us that sprint goal is not possible anymore or it doesn’t make sense anymore, something fundamentally changed for example, it can be a change in the market.
22:21.500 – in that case, what would you do? you won’t continue the sprint with the sprint goal that doesn’t make sense anymore you will just cancel the sprint in the middle of the sprint and then you will start the new sprint.
22:38.500 – and the only person who has the authority to cancel the sprint is the product owner.
22:45.500 – but you should know that it doesn’t happen so much you may have many projects without any cancelation at all and if you have maybe it happens once or maybe twice in a project, it’s something special.
23:01.500 – ok, alright so that was it about sprints and in the next lesson we’re going to talk about sprint planning.

In the next lesson, we’ll talk about the Sprint Planning event.

Lesson 05: Sprint

Contact your trainer to ask questions