Scrum Planning Tutorial

7.1 Scrum Planning

Welcome to lesson-7 of Simplilearn’s Agile-Scrum training program. In this lesson, we take a long, hard look at Planning of Scrum projects. We shall cover release planning as well as sprint planning. We shall look at the levels of planning; the principles of planning as well as the best practices that help us do a good job at planning. In the next slide, we will first look into the agenda.

7.2 Agenda

Let us now look at the detailed agenda for this lesson. We start off by setting up some “first principles” that guide us through the planning of Scrum projects. We look at the multiple levels at which planning takes place and how plans get progressively elaborated. Then we look at release planning and Sprint planning with the help of some examples and illustrations. Let us now talk about the Principles behind Agile planning.

7.3 Principles behind Agile planning

Planning in Agile is in itself an iterative activity. Unlike conventional projects, where plans are considered water-tight and concepts like “baseslining of plans” are prevalent, Agile recognizes the fact that plans are “speculative”. Remember the Agile manifesto, which says “we value responding to change over following a plan”. Here are some of the things to be kept in mind while starting out on planning. - Planning is speculative. You start out with a reasonable forecast based on available information and refine the plan as you go along. - The plan is elaborated and becomes more and more clear over a period of time - Planning is based upon the principle of time-boxing. You start out by fixing the time and resources available and then figure out what can (and what cannot) be accomplished with this - The plan has to be necessarily flexible and responsive to changes. Planning is an on-going activity - One should try not to pack too much into plans. The goal is not to be aggressive with planning – it is to be predictable. Changes are inevitable in any project and more so in Agile, because we want to show working demos to customers and they are guaranteed to want some changes after seeing working software. If your plan is too tight, you will not be responsive enough to these changes. Let us now look into a diagram in the next slide which describes Iterations allow for mid-course corrections.

7.4 Iterations allow for mid course corrections

The fact that we are developing in an iterative manner allows for mid-course corrections while working on a release. The release plan that you set out up-front is an initial guess at the plan. As the team works on the sprints, it also gets a reality check about the actual size and complexity of the tasks it has undertaken. It may also gain from the feedback received from the customers and other stakeholders. Based on this knowledge, the team should try to steer course of the project towards the goal. At the same time, the stakeholders should also work on adjusting their goals in the face of reality. So in reality, rather than fixing the goal, the stakeholders may want to define (and keep adjusting) a zone of success within which they expect the results to lie. For example, in the illustration, even though the actual completion was different from the planned completion, as long as the project parameters lied within this “zone of success”, it should still be considered a successful project. Next, we will discuss on multiple levels of planning.

7.5 Multiple levels of planning

Agile projects are planned at multiple levels, which are often represented through the “planning onion”. The planning could be at a daily, iteration (few weeks), release (few months), product (up to 2 years), portfolio and strategy levels (long term). The team is involved at the daily, iteration and release levels. The daily planning happens via the daily stand-up meeting. The iteration plans consider the tasks needed to accomplish the goals for a planning horizon of a few weeks. Iteration plans happen at the beginning of -each iteration. Release planning is driven by the need to convey a plan to the customers of the product about what they can broadly expect to happen over the next few months. More long term planning is typically driven by the Product owner, who needs to look beyond the immediate release to come up with a product roadmap (typically extending up to 2 years). Beyond the roadmap, there is planning at the portfolio and strategic levels wherein the organization determines whether this product is placed within the portfolio of the organization and what strategic needs it addresses within that portfolio. Now, we will understand the Release planning.

7.6 Release planning

A release plan is essentially a roadmap of how the team intends to achieve the vision of the project by implementing the features laid down in the project data sheet and meeting the overall objectives for the project, while working within the constraints of the project. The release plan is an important artifact for the product owner, who can communicate to the project’s stakeholders about what they can expect from a given project. It helps the product owner and the whole team decide how much must be developed and how long that will take before they have a releasable product. It also helps the team gain an understanding about the expectations and plan accordingly. A release plan is basically a guide-post that channelizes the energies of a project team in a particular direction. Let us now look into the next illustration which describes the Steps to planning a release.

7.7 Steps to planning a release

This diagram shows the typical flow of activities during a release planning session. First, the product owner must elucidate his or her vision for the product. This forms the “conditions of satisfaction”, which may include the expectations about scope, schedule, quality, etc. The team then estimates the stories required to achieve the vision. It will further seek prioritization among the stories, accordingly slot the stories into time-bound iterations. For doing so, it may need to develop an estimate of the “velocity”, or the amount of work that it can complete in a given iteration. At the end of this process, the team should arrive at the release date and inter-mediate milestones. In the process, it selects what it will develop, how long it will take and how much it would cost. This plan is then compared against the expectations and the team iterates this along with the Product owner for as long as it takes to achieve a satisfactory balance between expectations that the stakeholders of the project have (represented by the product owner) and the commitments that the team can make. Now, we will focus on the release planning.

7.8 Release Planning

This is how a release plan will end up looking like. It will assign the set of “candidate user stories”, to specific Sprints within the release typically the first two or three Sprints would be well defined, whereas the remaining will be left relatively loosely defined, in order to be flexible to adapt to the situation. The end goal of a release plan is to set expectations with the project’s stakeholders about what they can expect from the end product as well as potentially from each increment of functionality that comes out of the Sprints. The purpose of Release Planning is to define the contents of a release or a specific shippable product increment. In the next slide, we will learn about Velocity.

7.9 Velocity

Velocity is a measure of a team’s rate of progress per Sprint. An important metric that the team will use in planning is its “Velocity”. Velocity helps the team understand how much progress they can expect to make in a given Sprint. It is calculated by summing the number of story points assigned to each user story that the team completed during the Sprint.The velocity is simply the sum total of the size of functionality that the team delivers in a given Sprint. And by knowing the velocity data for the past several Sprints, the team can say with confidence how much work they normally get done in a Sprint. For example, if a team completes four stories in a given Sprint having sizes of 5, 3, 7 and 5 respectively, then the velocity is simply 5 + 3 + 7 + 5 = 20. Let us now go through an example with velocity= 14.

7.10 An example with velocity equal 14

If the team knows what its normal rate of working is, it can use this information for planning its work. In this instance, assume that the team has a velocity of 14. Knowing this, the team can select the stories to work on in any given Sprint, based on the sizes of the stories. For instance in Sprint 1, the team may start assigning stories to the Sprint in priority order. Story A had an estimate of 5 and Story B had an estimate of 8. At this point, the team has remaining capacity for only 1 more point, for which it may select Story E. It now has enough work to fill up Sprint 1. On similar lines, for iteration 2, it could pick stories C, D, F and G, again adding up to a size of 14 (3 + 3 + 3 + 5). That leaves stories H (13 points), I (5 points and J (8 points) that may tentatively be assigned to Sprints 3 and 4, leaving room to adjust the plan if there are surprises and/or changes along the way. So in collaboration with the Product owner, the team will select the best possible combination. One that aligns best with the priorities set by the Product owner and which the team will consider as “doable” based on the past data available about its velocity. In the next slide we will look at the Sprint planning.

7.11 Sprint planning

Let us re-visit our Scrum life-cycle picture to understand the context of Sprint planning. This is a very important meeting right at the beginning of a Sprint, where the teams with the help of the product owner selects which stories from the backlog it will accept for implementing in the current sprint. Getting into the rhythm of making good, reliable sprint plans is an important success factor for the team. We will continue with the Sprint planning in the next slide.

7.12 Sprint planning

The goal of the Sprint planning meeting is for the team to make a “good commitment” about what they will deliver at the end of the sprint. The meaning of good commitment is that: - Everybody is clear about the goal - Everybody believes that it is achievable The goal of the Sprint should be achievable without cutting corners or sacrificing on quality and further it should be achievable without sacrificing sustainable pace (do not plan on the whole team working overtime for the duration of the sprint). Especially in case of distributed teams, some Sprint pre-planning and advance story grooming activity with the product owner helps to keep the planning session short. Now, we will talk about the Velocity driven sprint planning.

7.13 Velocity driven sprint planning

This graphic shows the approach that the team may take to plan a sprint if they have a pretty good idea about what their velocity is. They proceed to determine the target velocity and get the backlog prioritized. Remember that the velocity may vary slightly from the steady state due to occurrences like vacation plans or pre-occupation with other (non-project) commitments, etc. Then they would identify a goal for the sprint based on input from the product owner. Based on the goal, they would select as many stories aligned with the goal as they can accommodate within the target velocity. These stories will be further broken down into tasks and the tasks will be estimated by the person who is assigned to the tasks. Next, we will discuss on Commitment driven sprint planning.

7.14 Commitment driven sprint planning

This graphic shows a different approach to sprint planning, which is based on the commitment that the team is willing to make. - First the team will identify an overall sprint goal and adjust the priorities of the stories with the help of the product owner. - Then in the order of priority, they will pick each story, break out into tasks and get the tasks estimated. - Once the estimates are available, the team discusses whether they are able to make a commitment to deliver that story collectively. If they can, it is added to the sprint backlog and the process moves on to the next story. - If they cannot, the story is removed from the backlog and the team can figure out if their capacity is fully utilized (cannot accept any more stories) or if there are other stories that can be considered. The sprint planning session ends once the team has figured out in this manner a list of stories that they can commit to. The reason this approach is useful is because it focuses on the process of the team making a COMMITMENT. The sprint planning is meaningful only if the team feels committed to delivering on the plan. So the process should drive towards the entire team making a GOOD commitment. Let us now find out how much time is available.

7.15 Find out how much time is available

During the course of sprint planning, it is important to understand what the team’s “availability” is. This should take into consideration leave days, the amount of time the person is available on a typical work day. The available time should take into consideration factors like: - Time to do some hacking, blog reading and independent research or work on pet projects (what Google calls 20% time), - Breaks taken during the day (lunch, tea or any other), - Email, - Meetings (not directly connected with work), - Fixing priority issues from previous releases, - Time that is committed to other teams, etc. We will now proceed to the next slide and learn about what the tasks are required for each story.

7.16 For each story

Having ascertained the time available from each person, we then look into a story and figure out what “tasks” are required to be completed before the story can be considered complete. For example, a story may have the following tasks. - Design and design review - Coding - Unit testing - System and regression testing - Documentation - Bug fixing, etc. The tasks have to be then assigned to individual team members. At this point, the tasks may need to be re-estimated because the estimate of each team member may differ. The team also needs to make sure that the team member has time available to work on those tasks. Let us now focus on the important points which we have to keep in mind before finalizing the plan.

7.17 Keep in mind before finalizing the plan

Before finalizing a plan, it may be a good idea to double check that: - Everybody in the team has enough work (and not too much work) to do - Has the correct capacity been considered? - Do you have buffer to accommodate certain amount of unplanned activities (e.g. sick time) - Has time required for scrum rituals been considered? - Have the dependencies been properly understood and tied up? - As of now, we have completed many important topics on Scrum Planning; let us now look into few quizzes in the next slide.

7.18 Quiz

Let us quickly test our understanding of this lesson through this quiz. Which of the following BEST expresses the term “release”? A- A time-box of 1-4 weeks in which to produce the next increment of software B- A portfolio decision that expresses future direction C- A project that creates an official, supported version of the software D- A test deployment given to an internal customer to play with Answer is C: A release is an official, supported version of a product. During a sprint, the team completed 5 stories having story points 5, 8, 3, 8 and 13. 2 other stories having story points 8 and 2 are 50% complete. What is the velocity of the team? A- 37 B- 42 C- 47 D- Cannot be determined from the data provided Answer is A: Only completed stories are counted for velocity calculation. Hence the velocity is 5 + 8 + 3 + 8 + 13 = 37. If the velocity of a team is 68 and the release backlog is 500, how many sprints are needed to complete the release? A- 8 B- 7 C- 6 D- 12 Answer is A: The number of sprints needed = 500/68 = 7.35. It is more than 7, so the best answer is 8 sprints. In the second week of a 2 week sprint, the team realizes that it cannot complete all the stories in the sprint backlog and is figuring out which feature to drop. Who is responsible to take this decision? A- Scrum master B- Product owner C- Customer D- Manager Answer is B: The product owner should be asked to make a call about which feature to drop. We thus end this lesson on Scrum Planning. We hope that this has been a pleasant experience for you. Let us move on to the next lesson. The next part covers eighth lesson of this course which is about Scrum estimation. Happy learning!

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*