Lesson 13: Sprint
The first event that we’ll talk about is the Sprint, which is also a container for the other events.
2020 update notes
A few things have changed in the latest version of the Scrum Guide (2020), and the ASF exam is updated based on those changes. However, our videos are not updated yet; so, please note the following changes:
- There’s no “development team” anymore, but only Developers.
- The recommended team size is now “10 people or less” for the whole Scrum Team.
- It’s now called “self-managing” instead of “self-organizing” (same concept, different name).
- There’s a Product Goal now, which is part of the Product Backlog, and sets the overall direction for the product.
- The Sprint Goal is now considered as part of the Sprint Backlog.
- The concept of commitments is introduced for the artifacts:
- Product Goal is the commitment for the Product Backlog.
- Sprint Goal is the commitment for the Sprint Backlog.
- Definition of Done is the commitment for the Increment.
- The Definition of Done is created by the whole Scrum Team now, and not only by the Developers.
- Now, any time you finish an item (based on the Definition of Done), a new Increment is formed. It’s not about having just one Increment at the end of the Sprint.
- The guide doesn’t suggest 10% as the ceiling for the amount of time Developers spend on Product Backlog refinement.
- Sprint Planning has three topics now:
- Why? -> Sprint Goal
- What? -> Items from the Product Backlog
- How? -> Tasks created by decomposing the items
- “Estimating” is now called “sizing”. So, it’s the responsibility of the Developers to size the Product Backlog items.
- “Value” is no longer one of the mandatory attributes of the Product Backlog items. The mandatory attributes are description, size, and order.
- Instead of calling the Increments “potentially releasable”, the new guide calls them “usable” (more or less the same concept).
- 00:06 – The first event that we’re going to talk about is the Sprint.
- 00:11 – Do you remember the more generic name for Sprint? The one that I used in the first section?
- 00:16 – That was Iteration.
- 00:18 – We call it Iteration because we iterate, we repeat the development processes.
- 00:23 – We analyze, design, construct, integrate, test.
- 00:27 – If it’s about IT development, of course.
- 00:30 – So, there are a few things about Sprints that we need to talk about.
- 00:34 – Of course, the first and most obvious thing is that Sprints are timeboxed, which means that they have fixed duration.
- 00:41 – We don’t expand them. Never. Not at all.
- 00:45 – It doesn’t matter if you’re not done with everything.
- 00:48 – You will finish your Sprint and you will deliver whatever you have done.
- 00:52 – That’s fine. That’s not the goal, to finish everything. The goal is to generate value.
- 00:56 – Remember, that’s the most important thing here.
- 00:59 – And the duration for the Sprint. Do you remember there was a difference?
- 01:04 – Do you remember the maximum duration that we had in the Agile principles?
- 01:09 – Yeah. The maximum duration based on the principles is 2 months.
- 01:14 – But the maximum in Scrum is 1 month. Okay?
- 01:19 – So, your Sprints should not be longer than 1 month.
- 01:23 – You should not timebox them for more than 1 month.
- 01:26 – But it’s up to you. You decide about the duration of your timeboxed Sprints.
- 01:32 – Now, the question is, and we’ve talked about it before a little bit, but again, are you going to have the time … Sprints with the same duration or with different durations?
- 01:46 – Which one is better?
- 01:50 – If your Sprints have the same duration, then it’s simple.
- 01:54 – You know that each time, it’s going to be 2, 3 or 4 weeks, you don’t have to make any decision, but if you’re going to have different sizes, then each time, before each Sprint, you have to discuss the duration of the Sprint.
- 02:10 – You have to decide how long you’re going to work on that Sprint.
- 02:15 – That takes some time and effort, and the first one is more straightforward, isn’t it?
- 02:23 – That’s why in Scrum, we prefer the first option.
- 02:27 – We have the same size for all Sprints.
- 02:31 – It doesn’t mean that you’re not allowed to change them.
- 02:34 – You, for example, go on with your project and after 3 Sprints, you’ve selected to have 2-week Sprints or 4-week Sprints.
- 02:42 – And after 3 Sprints, you realize that it’s too long, you can have shorter Sprints and you know that shorter Sprints are better, if you can.
- 02:51 – So, you make a decision that from now on, we’re going to have 3-week Sprints instead of 4-week Sprints.
- 02:59 – That’s absolutely fine. No problem at all.
- 03:02 – What we don’t do is to make ad hoc decisions each time we want to start a new Sprint.
- 03:08 – Okay. What’s the goal of the Sprints?
- 03:13 – That’s very simple. We want to create a piece of working software.
- 03:17 – We want to create a piece of product.
- 03:20 – One version of software that has more features than the previous one.
- 03:25 – In Scrum, we call them Increments. Increments of product.
- 03:30 – Do you remember the difference between Incremental Delivery and Iterative Development?
- 03:36 – One of the first lessons? Yeah. That’s it.
- 03:40 – So, our goal is to create increments, valuable increments.
- 03:45 – We want to generate as much value as possible through increments.
- 03:51 – A piece of software that works well and if it is put into production, it can generate value, and also one that can generate the highest value possible, which means that if you want to do that, you should be careful with items that you pick for your Sprint.
- 04:14 – That’s going to be our topic for Sprint Planning.
- 04:17 – So, that’s the goal here.
- 04:21 – Not … your goal is not to develop everything that you’ve picked for the Sprint.
- 04:27 – I’m going to repeat it many times.
- 04:30 – People think that you’re not a good development team if you cannot deliver everything.
- 04:34 – That’s absolutely not the case. Your goal is to maximize value, and there’s a difference, we will talk about the difference.
- 04:42 – The other misconception about Scrum is that many people have something like Sprint 0 in the beginning of the project to prepare for the project, to create the infrastructure or the development environment and things like that.
- 04:58 – It is not acceptable in Scrum.
- 05:03 – So, why is it not acceptable? What do you think? That’s one question.
- 05:10 – The other question is if we are not allowed to have Sprint 0 to prepare for our project, prepare tools and infrastructure, then when do we do that?
- 05:20 – That’s my second question. Okay.
- 05:24 – For the second question, we do it gradually during the project.
- 05:29 – That was simple, right? Like everything else.
- 05:32 – How do you design your project? How do you handle your architecture?
- 05:35 – Gradually.
- 05:37 – What do you do with your plans?
- 05:39 – It is done gradually. Everything is done gradually.
- 05:43 – For the tools and infrastructure, they are mainly done in the first few Sprints.
- 05:49 – After that, you won’t need much more and still, besides preparing, we will also do some actual work, some actual development because we must have increments at the end of each Sprint.
- 06:06 – So, we don’t have a Sprint 0, we start with Sprint 1 and all the Sprints are the same.
- 06:13 – We also don’t have Integration Sprints, Hardening Sprints, any other type of Sprint that you can think of. They’re all the same.
- 06:23 – Now, my other question.
- 06:25 – Why is it not a good idea to have a Sprint 0 and do all the preparation upfront?
- 06:30 – What do you think?
- 06:33 – For the same reason that we don’t want to have upfront planning and upfront design because when you do all the preparation upfront, each type of preparation is more suitable for a certain type of development, for a certain type of product, and then you’re somehow fixing the way you want to go in your project that limits your adaptation.
- 06:57 – We don’t want to limit our adaptation. That’s the most important thing.
- 07:01 – And also if you want to spend some time only preparing, then you won’t be able to receive feedback and your adaptation will happen later.
- 07:11 – That’s not a good idea.
- 07:14 – If we can do it gradually, then we will be much more successful in our projects, and as it happens, we can do it, so why not.
- 07:24 – Okay. One more thing about Sprints.
- 07:29 – In the beginning of each Sprint, we decide about the number of features that we want to create.
- 07:35 – We put them in the … do you remember the name?
- 07:38 – The Sprint Backlog.
- 07:40 – I had to think about the name. Okay.
- 07:43 – So, we pick a number of items, we put them in the Sprint Backlog, and then we focus on those items and our goal is to create the product.
- 07:52 – Do you remember the name of the product? The Scrum name for the product?
- 07:55 – Increment.
- 07:58 – So, our goal is to create an increment based on those items in the Sprint Backlog, but the question is what happens if, for example, you start with certain features for that Sprint, and in the middle of the Sprint, you realize that based on some changes in the market, those features are not needed anymore, or your previous increments are in production, you’ve released them, and now you have … something has happened, a new regulation or something, and you have to develop new features as soon as possible.
- 08:31 – It doesn’t … the existing features don’t make sense anymore. What do you do?
- 08:36 – We don’t want to keep changing the Sprint Backlog all the time.
- 08:39 – It’s not a good idea to remove all the items from the Sprint Backlog and add new ones.
- 08:44 – So, what we do instead of that is that we cancel the current Sprint and start a new one, and the only person who can cancel the Sprint, who do you think it should be? Let me ask you that.
- 09:03 – Who should be able to cancel the Sprint?
- 09:07 – You remember that we only have three roles and it has to be one of them.
- 09:12 – When we want to cancel the Sprint, it’s mainly something related to value because if it’s going to be technical, then we have to solve that technical problem.
- 09:23 – It’s mainly an issue with value that forces us to cancel the Sprint.
- 09:29 – So, that makes the answer very simple. It has to be the Product Owner who can cancel the Sprint.
- 09:36 – Okay. That was about the Sprint, and now inside the Sprint, we have four other events.
- 09:41 – We’re going to talk about the Sprint Planning in the next lesson.
Next is the Sprint Planning event.
Here you can submit your questions related to the content of the course. (For other questions, use the support system). The trainer's reply will be email to you in 48 hours.
The first lessons of the course, including this one, are available for free, even without registration.
You can purchase the course to access all lessons, additional material, and coaching:
More info and purchase options