Lesson 14: Sprint Planning

How do we plan a Sprint?

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:05 – Okay. So, we have Sprints, and for each Sprint, we’re going to pick a number of items, focus on them, and complete as many as possible until the end of the Sprint.
00:21 – We will show it to the customer, receive feedback, and see what we’re going to do in the next Sprint.
00:26 – So, as you see, it all starts with thinking about the items that we’re going to have, the features that we’re going to work on during the Sprint.
00:36 – And that’s done here in the Sprint Planning.
00:39 – It’s an 8-hour timeboxed meeting when we have a 1-month Sprint.
00:46 – If your Sprints are shorter, it will be shorter proportionally.
00:49 – For example, for a 2-month Sprint, it will be 4 hours normally, but it is timeboxed, so it won’t be longer than whatever it has to be, but if you’re done before that time, it’s okay. You will finish the meeting and you’ll go on with the other things that you have to do.
01:08 – There are two main outputs for the Sprint Planning.
01:13 – One is the Sprint Goal and the other is the Sprint Backlog.
01:17 – The Sprint Goal is a relatively abstract idea in the overall purpose that we have for this Sprint.
01:30 – Something more than the combination of the items that we will have in the Sprint Backlog, and it’s used mainly to give direction because we do have those items in the Sprint Backlog, different features; for example, the capability to print something in our software.
01:51 – Now, for each feature, you can have different interpretations.
01:56 – Part of that, the specification for each item, is included in the composition of that item.
02:03 – You’ve talked about it with your customer, you’ve made the decision and you will do that, but still there is more to it, and that’s something that you will do during the Sprint.
02:13 – Now, to give you some help in understanding or deciding what to do or how to realize each of those items, you will have the Sprint Goal.
02:26 – Now, it’s not always as easy as that.
02:31 – Can you think about a few Sprint Goals?
02:36 – Some of the things that we’ve had in our project, for example.
02:40 – It could be something like this.
02:43 – By the end of this Sprint, we would like to have some changes in the software that makes it as easy as possible for the user to interact with that certain part of the software.
02:57 – You see, this is more … this is not exactly features.
03:02 – It’s something that we can use to interpret those features and, of course, not everything that you have for the features will be covered with the Sprint Goal, obviously. It’s just to help. Okay.
03:15 – So, that’s one of the outputs, and the other output is obviously the Sprint Backlog, and what happens is that we have the Product Backlog and who’s …
03:26 – who manages the Product Backlog, do you remember?
03:29 – That’s the Product Owner, because the way we manage the Product Backlog affects the way …
03:35 – the amount of value that we’re going to generate and the Product Owner is responsible for value.
03:41 – So, we have the Product Backlog and the Product Owner has ordered all the items in the Product Backlog.
03:49 – Now, when it’s the Sprint Planning meeting, everyone will get together, all three roles, and then the Development Team will check the items on the top of the Product Backlog and they see how many items they can finish until the end of the Sprint, and it’s important to note that it’s only up to the developers to decide how many items they want to do.
04:14 – No one else such as the Product Owner or the Scrum Master will tell them what to do, especially the Scrum Master because, as you remember, the Scrum Master doesn’t have anything to do with the content. This is about the content.
04:29 – The Scrum Master is only focused on the context and the problems that they have.
04:34 – So, in many projects, the Scrum Master or the Product Owner go to the Development Team and tell them, “Okay, here is what you have to.” That’s not correct because when you do it like this, then these people won’t have – you won’t have their buy-in.
04:50 – You can never be sure that they are capable of doing that.
04:54 – Maybe if you let them do it, they will pick the same number of items, but because it was their decision, they will do more to make sure that they can do it.
05:04 – That’s important for us. We are focused on productivity and generating value, not to do as much work as possible.
05:13 – So, the development decide on the number of the items they can do. It’s a guess.
05:18 – Nothing happens. There is no … in the past, we used to use the word commitment here, and still you see commitment in many different resources, that when they pick those items and put them in the Sprint Backlog, they are committed to do that until the end of the Sprint.
05:39 – We don’t do it much. They are not committed to do all those work, to finish all those work.
05:46 – They are committed to do their best in order to do that, and maybe we shouldn’t even use the word commitment here anymore.
05:55 – That’s their guess. That’s what they think is realistic to do.
06:00 – So, they create the Sprint Backlog and that would be their plan for the Sprint.
06:09 – Now, it’s up to them to decide how they want to do it and they own the Sprint Backlog, you know.
06:15 – In the same way that the Product Owner owns the Product Backlog, the developers own the Sprint Backlog, which means that they are the only people who will touch the Sprint Backlog.
06:26 – No one else goes there and makes changes in the Sprint Backlog.
06:30 – Now, if they decide, they can have a big board.
06:34 – Almost everything in Scrum is on physical boards, that’s a good idea unless, of course, you have virtual teams.
06:40 – So, it can be a board like this, and in case you are familiar with that, it’s a type of very simple Kanban board because we have columns - To Do, Doing, and Done. That’s Kanban.
06:53 – Well, not entirely, not really, but resembles Kanban.
06:58 – We will talk about Kanban in the last section.
07:02 – So, they can create a board like this and then they will put the items that they have selected from the Product Backlog in here.
07:11 – But as you see, we have two types of items here.
07:15 – One is the items that they pick from the Product Backlog, those are the features, and later on, we will talk about the concept of user stories. They can be user stories.
07:28 – Think about them as features for now.
07:32 – That’s one kind of thing that we have in the Sprint Backlog, and the other thing is that imagine you have an item like resetting password.
07:43 – How do you do that?
07:45 – You have to do different things in order to create that feature.
07:49 – For example, you need an interface to interact with the user, you need a way to authenticate the user and see that they can receive the new password or set a new password.
08:01 – Then, you have to receive the password, put it in the database, update anywhere that it is needed.
08:08 – Maybe you need to check if the password is strong enough.
08:12 – These are the tasks that they … that you do and it’s a good idea to have your tasks in the board.
08:20 – That’s the second type of elements that we have here.
08:24 – So, we have the items we pick from the Product Backlog and then we break them down into the tasks that you need to create those items.
08:35 – Alright? Now, there’s one thing here.
08:39 – Imagine it’s the Sprint Planning. It’s like a small project. Okay?
08:44 – Now, inside this small project, in the beginning, you have some type of planning and you know that in Adaptive systems, we don’t want to have detailed upfront planning because that doesn’t let us adapt. Okay?
08:59 – And the same thing happens here. Even though we have this type of plan, we still need to adapt during the project.
09:05 – You go on, you talk to your customer, you change your mind, this is only your guide, and therefore, if you try to create all tasks here in the Sprint Planning, that would be a type of upfront planning that will block your adaptation.
09:22 – That’s why in the Sprint Planning, you will only create tasks for the first few items.
09:28 – Something that you will need in the next 3 or 4 days of work.
09:32 – You don’t do it for all items.
09:36 – When do we do that? During the project … during the Sprint.
09:41 – So, in the beginning, you have something like this, with only a few tasks for the items on the top, and then when you go on, you will add more and more tasks to your Sprint Board.
09:53 – And also, you remember that in the Product Backlog, items that are on the top are more important, right?
10:02 – That’s why we go and pick items from the top.
10:05 – Now, the same order will be here in the Sprint Backlog, the same order that they had in the Product Backlog.
10:13 – So, items on the top of the Sprint Backlog have a higher priority and therefore it’s a good idea to always follow that priority, that order let’s call it, and start from the top of the Sprint Backlog because we know that it’s always possible that we don’t have time to finish everything that we have in the Sprint Backlog.
10:32 – So, if we don’t have time, we prefer those undone items to be one of those on the bottom that are less important rather than more important items on the top. Okay?
10:44 – So, that was it. The Sprint Planning meeting, and in the next lesson, we will talk about the Daily Scrum.

Lesson 14: Sprint Planning

Contact your trainer to ask questions