Lesson 06: Sprint Planning

What?! Do we PLAN in Scrum?!

00:05.500 – Welcome back, in this lesson we’re going to talk about sprint planning which is one of the five events in scrum and as you remember we the sprints one after the other without anything between each two sprint and inside the sprint which is a container for the other four events we start everything by sprint planning like every other event in scrum sprint planning is designed to be a formal opportunity for inspecting and adapting the artifacts that’s the same for all of them it’s about inspection, adaptation and .. do you still remember the third one?
00:48.500 – transparency. we start by transparency and in each of these things we have different artifacts that help us increase transparency and it’s not only about artifacts we have different elements that help increase transparency.
01:02.500 – we use the transparency to inspect and we inspect in order to adapt.
01:10.500 – so here like everywhere else we have transparency, inspection and adaptation the other thing is that when it comes to daily scrums, we really really want them to be at the same time and place every working day, because otherwise it doesn’t make sense to plan for a 15 minutes meeting.
01:38.500 – so, that’s obvious for daily scrums, but even for the rest of them we still prefer to have them at the same time and place every time.
01:48.500 – so, for example if you have monthly sprints then maybe you can have a plan to have your sprint planning on the first day of each month in your special room which is something else, in agile we prefer to have a room for everyone to work together it’s not like having people in different departments of the organization contribute into the project we want them to be collocated.
02:19.500 – ok. so like every other event sprint planning is timeboxed.
02:26.500 – do you remember the meaning of timeboxing?
02:29.500 – it means that it has a predefined duration and we never never ever extend that duration and because we know that we won’t do that then when we are doing the sprint planning things we have to be careful we have to be mindful about the thing we do and focus, focus is important later on we will see that focus is one of the values in scrum, we have to focus on the agenda for sprint planning and on the most important things in that agenda.
03:04.500 – on in other words, the time that we normally have for sprint planning is really enough for sprint planning if it’s not enough you have different type of problem somewhere else and you have to find it and fix it and when do you usually find those problems and plan for improvements that’s usually the sprint retrospective, you’re not limited to that but that’s the structured way of planning for your improvements.
03:32.500 – so coming back to sprint planning it is timeboxed but how long?
03:37.500 – the maximum is eight hours.
03:41.500 – and usually you have timeboxes of eight hours when your sprint is one month which is a maximum duration for sprint, and if your sprints are shorter then it will be shorter than eight hours in the past, in the beginning it used to be proportional so the advice was that if you have a two weeks’ sprint then you need to have sprint planning of four hours but it’s not recommended like that in the scrum guide anymore it just tell you that it’s maximum of eight hours and it’s up to you to decide how long you want it to be.
04:17.500 – for example, you can still have a monthly sprint and decide to have six hours for your sprint planning you timeboxe it to be six hours or you may have one week long sprints and still decide for some strange reasons to have eight hours for your sprint planning that’s fine according to scrum guide Ok.
04:44.500 – this meeting is for the internal team the developers, the scrum master and the product owner they get together and plan the sprint.
04:54.500 – but in addition to that, they may invite some other people to join them to for example, provide them with some expertise, some information or some ideas about the way they can work during the sprint, that’s ok.
05:08.500 – something else, that is general in scrum and yeah in most agile systems is that when we say that this meeting is for these people it doesn’t mean that it’s confidential or private anyone else can come to the meeting but as long as they just observe and don’t talk.
05:29.500 – they’re just there to see what happen. for example, another team in your organization whose using scrum, they want to come to your sprint planning and see how you are doing your sprint planning, to get ideas and improve their own sprint planning it’s ok as long as they stand in a corner and don’t talk, as long as they don’t distract you.
05:51.500 – Ok. so we get together, we prepare and we have three different goals here.
05:58.500 – we need to answer these three fundamental questions why are we going to do this sprint?
06:05.500 – what are we going to do?
06:07.500 – and how are we going to do that?
06:09.500 – so, one at the time. Although the first two don’t have an order I tell you about that later.
06:20.500 – so, they why part why do we want to do this sprint? what’s our objective? what’s our goal?
06:27.500 – that’s when we create a sprint goal.
06:31.500 – I’ve talked about it before, because our goals are more than the sum of the items that we work on.
06:37.500 – the goal is something that direct us in understanding the items we are going to work on.
06:46.500 – for example, you remember we talked about the sprint backlog and product backlog in the first lesson and we’re again talking about here so the item is not extremely different the scope of the item is different, adapt is different but the most important difference is that I had a different goal for the first lesson. in the first lesson I just wanted you to have an over understanding of scrum but now I want to tell you everything about the sprint planning.
07:17.500 – so even now I won’t go through all the details related to sprint backlog because we have another lesson about it.
07:24.500 – here we are focused on sprint planning.
07:27.500 – so that’s how I interpret the item to talk about the sprint backlog in this lesson you see that’s the same in your projects so anyway, all of them together the developers, the scrum master and the product owner decide about the sprint goal.
07:48.500 – ok.
07:50.500 – the second thing that we have to do is to think about what we are going to do?
07:55.500 – and the first question really helps us, why are we going to do it? ok now we know why we are going to run this sprint now what are we going to do exactly. it’s going to be more contrite now and the way we do it, is that we pick a number of items from the product backlog and bring them to the sprint backlog.
08:15.500 – it’s absolutely 100% up to the developers to decide how many items the want to pick because they know best how much capacity they have, how much work they can do.
08:29.500 – but the items that will be selected, which item will be selected in which order we will go through the product backlog that’s up to the product owner, ordering the product backlog is the accountability of the product owner.
08:45.500 – so, we pick all of them, not all of them, as much as we believe we can to in one sprint as developers.
08:55.500 – now something that we usually have here is that we need to think about items in the product backlog are we ready to do that item?
09:08.500 – what does it mean for an item to be ready?
09:11.500 – for example, you may have an item there telling you the example we have before the CRM customer relationship management feature for our application is huge so if you see an item like that, you go .. ooh.. ok so it’s just mentioning a CRM, but what do you mean by a CRM?
09:33.500 – what type of features you want to have in a CRM?
09:37.500 – if they give it to you, you can’t even estimate you can’t size that item because it’s not clear enough as if it’s not ready.
09:48.500 – so practically when we talk about being ready for an item it means that it’s ready to be developed in the upcoming sprint and you can’t finish it in one sprint and in order to do that it has to be small enough to fit inside one of the sprints and it has to have the information you need to order to do it for example, saying that we want to have a CRM that’ not enough.
10:17.500 – you need to say what type of features you want?
10:20.500 – so practically an item like CRM is not ready and typically a good product owner never lets the product backlog has such an item on top of it, because the items on top of the product backlog will be developed soon when they see that there is an item like that on the top of the product backlog they will refine it, they will break it down into the smaller items they may add more information and so on.
10:49.500 – we will talk about it later it’s called refinement (product backlog refinement).
10:55.500 – but there is something else here what happens if you’re in the middle of the sprint planning meeting and you reach an item in the product backlog and you see it’s not ready would you skip that? would you cancel your sprint even though it’s not even started?
11:17.500 – would you extend you sprint? what would you do?
11:21.500 – and the proper answer is that if it’s really on top of the product backlog and the product owner believes that it needs to be there because it’s very important and very valuable for us then, we should pick it even if it’s not ready and then when we start working which is after sprint planning then we will get together with the product owner and we will refine it we will add more information, we may even break it down in to smaller items.
11:52.500 – so the main message here is that just focus on the value and order of the items don’t use readiness as a gates, gate is one of those things that scrum is very worried about, it’s one of the taboos somehow.
12:14.500 – remember the other taboos we talked about methodology, process and now we have gate. there is more I try to remember all of them and repeat them for you.
12:24.500 – ok so, the other thing that happen is that some people create something they called definition of ready.
12:32.500 – you already know that we have a definition of done which is absolutely necessary.
12:37.500 – by the way everything we talk about in this course are the things that are mandatory to have in scrum unless I tell you otherwise but there is no mention of definition of ready in scrum but it doesn’t mean that it’s forbidden, there are lots of things that are not mention in scrum and as I told you before scrum is a framework and then we will add different techniques and practices and extra things to it.
13:03.500 – Now some one may decide to add one extra thing called definition of ready now is it ok?
13:11.500 – because you know that even though we say that you will add extra things, some of the things are not acceptable you remember in previous lesson for example, we talked about the fact that we should not have special sprints like integration sprint or sprint zero.
13:30.500 – it’s forbidden to have.
13:32.500 – now what about definition of ready?
13:38.500 – you can have a definition of ready if you really want as long as you don’t turn it into a gate here.
13:47.500 – so if you create a definition of ready and use it as a gate to decide which items to pick and which items not to pick then that is wrong and you should not have such a definition of ready.
13:59.500 – but if you define it and only use it to make sure that everything is refined before the sprint planning meeting, then it’s ok.
14:07.500 – Alright, so you continue and pick the items that you want and that would be your answer to the What question.
14:18.500 – now well when you are doing that, you remember the three pillars of scrum; transparency, inspection and adaptation and yes I never mentioned the word pillar before, those three are called the pillars. we will have a different lesson for that. don’t worry.
14:35.500 – transparency is important, and one of the things that help us with transparency is the definition of done. as we talked about before because when you have a documented definition of done then anyone who sees something that you marked as done knows exactly what you mean. for example, does it also contain user documentation? is it part of your definition of done?
15:03.500 – that’s transparency. the other thing that it can do which is very helpful is that it helps you understand how many items you can pick for example, if you’re supposed to have a very comprehensive user documentation in your definition of done then you have to spend some time doing that and therefore you will have fewer items here; you need to have fewer items here.
15:27.500 – but if you don’t have that type of trouble in your project then you will be free to pick more items; you have more time in your sprint.
15:36.500 – so practically, what happens is that the definition of done is one of the things that help you as developers to understand how many items you can pick for the sprint.
15:47.500 – ok. so now we have the answer to the What question and our answer is the product backlog items that we picked for our sprint.
15:56.500 – now the thing that I mentioned in the beginning is that there is no exact order between the first two; the Why and the What question well, more or less we start with the Why question and then go to the What question but it’s a little bit iterative, so what is mean is that you think about the sprint goal, it’s still not finalized because you are in the sprint planning, you feel that you are happy about it as the all team and then start thinking about the items you pick the most important items and when you do that you see that the items that I’ve picked are not 100% aligned with the sprint goal now in response to that you may want to change the items or you may want to make some changes in your sprint goal based on that so the first two have a few rounds of negotiation they do it and then at the end you will have your sprint goal and your product backlog items.
17:08.500 – and then we have the third topic, these three are topics in sprint planning, the third topic is about how you’re going to do those things the first topic about Why is done by all those three people, the scrum master, developers and product owner the second one is mainly done by the developers and product owner and this last one is only done by the developers because it’s a technical decision; it’s a decision about the way we’re going to do the work and only the people who are actually going to do the work are allowed to make that decision.
17:44.500 – it’s 100% up to the developers.
17:47.500 – so they think about the items and in order to understand how you’re going to do that they will decompose those items in to small work items, well the scrum calls them work items we typically call them tasks but well task somehow has a negative connotation in some agile communities but..anyway, small technical things for example, your item maybe about resetting passwords in a website you want to add an extra feature to let users reset their password.
18:27.500 – now you start thinking about that you create those small work items, technical things, one of them is for example, the user interface one way of authentication, understanding that this is the same user for example, using the email address, or phone number or a security question like two hundred years ago something like that to make sure that the person is who they claim to be.
18:58.500 – another feature to receive the new password and for example, check to see if it’s a strong enough then you need another feature another task, another task to update your database another task to communicate the change to the user and so on. Alright so we go on like this but you remember that this is agile, this is adaptive we don’t do upfront planning if you stay here in your sprint planning and think about each and every item and plan all of them, this is a type of planning then it would be an upfront planning for your sprint and that’s not really ok because it blokes your adaptation a little bit, it’s not lean, it’s not just in time.
19:50.500 – so instead of that what you would do is focus on the first few items the thing you need to do in the first few days and for the rest of them you will continue planning during the sprint. as simple as that .
20:06.500 – ok and that was our third topic where we create those small work items (the tasks, but don’t tell anyone that they are tasks) ok we’re done with the sprint planning, in the next lesson we’re going to talk about daily scrum.

In the next lesson, we’ll talk about the Daily Scrum event, and other things that happen during a typical development day.

Lesson 06: Sprint Planning

Contact your trainer to ask questions