Sprint Planning

Loading...

From the course by University of Minnesota

Agile Software Development

66 ratings

University of Minnesota

Agile Software Development

66 ratings

Course 2 of 4 in the Specialization Software Development Lifecycle

Software industry is going crazy on agile methods. It is rapidly becoming the choice for software development where requirements are unpredictable or is expected to change over time. This course will help you gain knowledge on what is agile? Why agile is better suited for these situations? We will also cover some of the most common agile frameworks like scrum and XP in depth. Prerequisite: You need basic knowledge of software development process and software development methodologies. After completing this course, you will be able to : 1) Demonstrate the ability to participate effectively in agile practices/process for software development. 2) Explain the purpose behind common agile practices. 3) Ability to apply agile principles and values to a given situation. 4) Ability to identify and address most common problems encountered in adopting Agile methods. Project: You will also be given opportunity to apply what you learn in this course. You will be given fictional case studies, where after studying the case study, you will have to exercise some of the practices, techniques, etc that team members of an agile team members are expected to know.

From the lesson

Scrum

In this module we will learn about Scrum which is one of the most popular agile framework. We will learn about scrum practices and the purpose behind these practices.

Sprint Planning12:01

Sprint Tracking3:07

Meet the Instructors

Praveen Mittal
Adjunct Professor
College of Science and Engineering

In this video, we are going to learn about Sprint Planning and Tracking.

How do you plan a sprint and how do you stay on track?

So, in this diagram of Scrum,

the two areas we're going to focus on are these

two where the sprint planning is happening and then,

the burndown in a chart which are used to track sprint.

Before you do the sprint planning,

you need to do some prep work,

and let's go through that prep work first.

So, you want to make sure that your backlog is up-to-date.

So, to do that,

there's something called backlog grooming,

or sometimes people call it backlog refinement that needs to happen.

And so in this session,

however you want to do it,

whether in a meeting or you try to remove all the user stories that are not needed.

You'll create news stories,

or you assess the priorities of the stories,

you update the priority,

and then, if there are any estimates missing,

then you give that estimate,

and if there are estimate that needs to be updated, then you update those.

And if there are bigger stories that need to be split into

smaller so that they can fit in a sprint, then you do that work also.

So, all of these activities

happen either in a meeting or a session like backlog grooming,

or they can also happen without a meeting as well.

Then once the backlog is up-to-date,

then the next task is to select the story for the next sprint.

Now, sometimes this activity happen as part of the sprint planning,

but we'll just going to talk about what is it.

How do you select potential stories for a sprint?

You can either use the story map and just say, okay,

this is the area that we are going to work on in the next sprint.

Or you can use your prioritized backlog and just start from

the top and just pick stories based on your velocity.

The alternative is sometimes people select here is the one area we are going to focus on,

or sometimes if you want to learn something,

then they dedicate the whole sprint to that particular topic.

So, now once you have selected the story or potential stories,

you want to make sure that they are up-to-date,

and they can be worked upon.

So, you want to make sure the who, what,

why is specified for the story,

acceptance tests are written and if there are

any major dependency to work on those stories,

that are taken care of.

So, once this preparation is done,

the sprint planning session can happen or begins.

In the sprint planning,

you can do two possible ways.

One is in the one step where you just go from the top of your backlog,

take one story from the top,

task it out and say,

if my capacity is not reached,

then you take the next story,

and you keep doing that until your capacity is reached,

or you can do a two step process where based on your velocity from last sprints,

you select the story based on your predictive velocity for the current sprint and

then you take those stories and then you task it

out and validate that you can actually come into those stories.

Sometimes the teams don't do the step two of this two step process,

and they just select the story based on the sprint,

and they start executing.

So, what are the steps for sprint planning?

We determine the sprint capacity.

We review the sprint goal which is,

what is it that we're trying to achieve in the sprint.

We review the potential stories.

The product owner generally shares what are those stories and explain those stories.

And then, the team acquire

confidence by tasking out and having all the design discussions.

So, they talk about, like how are we going to implement these stories,

and what are the tasks that we need to do.

And then, if based on the step number four,

if the thing that they cannot achieve what was originally proposed,

then you might refine the goal.

Once that is done,

then the whole team make a commitment that yes,

we are ready and we commit to finish these stories.

And then once the commitment is done,

then you put the stories on the task wall and start executing.

Let's take each of these steps in more detail.

Determine capacity.

So, to determine capacity,

lets say the team had four people,

John, Erik, Kevin and Josh.

And so, you take a look at amount of days they are available,

and how many hours per day they are available to work on this project or this team.

So, in this case,

John is taking one day off.

So, its a two week sprint.

So, he's available only on nine days,

which means he's taking a day off,

or something else is happening.

And then, out of those nine days,

generally the whole team takes about two days for all these Scrum activities,

like sprint planning, or retrospective and review, and backlog grooming.

So, they want to deduct those two days from their capacity.

And John works close to 5 to 6 hours,

because he checks email in the morning, or in the afternoon.

So, approximately, he works for 5 to 6 hours.

So, that gives the available effort hours of 35 hours to 42 hours for a job.

And how it was calculated,

9 minus 2 give me the total days available,

and he works for 5 to 6 hours,

so that gives me 35 hours to 42 hours.

Similarly, you do the same thing for Erik, Kevin and Josh,

and then finally you total them up to get the total team capacity for the sprints.

So, in this case, it's 73 to 103.

73 came from 35 plus 10 plus 18 plus 10.

And then, the 103 came from 42,

12, 24, and 15.

Now, there are some simpler alternatives to determine capacity.

Sometimes team just take the total for

all the tasks that they finished in the last sprint,

or they take an average of total task estimate from last experience,

or let's say last three sprints.

So, those are the simpler alternatives to calculate the capacity for the current sprint.

Then the step number two,

you define the sprint goal.

And so, you say by the end of this sprint,

persona will be able to do this,

or something that the team can rally around.

The step number three is the reviewing the story.

So the product owner go to the story and explain everything,

what is going to happen in the story.

Now, during this part,

if the people or the developers or the team members are not asking question,

has to make effort to make sure that they are talking,

and they are asking question.

If nobody is asking question,

it's generally a bad sign.

And then you should also set up a definition of ready for the stories which means,

is it ready to be worked upon?

Like is everything that we need to know about the story is available?

Step number four is to acquire confidence.

Now, this one is where the team, the developers,

the testers they want to get together and talk

about these are the stories that we need to do.

What is it exactly that we need to do?

So, they create tasks and

then if there is any question, then they will ask their product owner.

So, product owner is needed only to answer questions,

but you don't need everybody in this meeting.

Mostly, the core team,

the developers are needed.

Now, in this meeting,

face-to-face conversation really helps because they can use the board,

they can design discussions.

And sometimes the discussion goes quite a bit.

And so, you have to make sure that you use some kind of

a time box tool to make sure that discretion is staying on track.

So, you can use a time box and after every five minutes if the discussion doesn't end,

you can ask, are we going in the right direction?

And then, you should estimate the task in ideal hours or days.

So, after step four,

then like I said, you can define the goal.

If based on the step number four,

you want to change the goal,

then you make a commitment,

and the step number seven is where you put all the task on the task wall.

So, that finishes the planning.

Now, some of the logistics about sprint planning.

Who to invite? Well, of course,

all the core team members.

But you can invite all the users or clients or business,

anybody who can help answer questions if any.

How long generally the sprint planning sessions are?

It depends quite a bit on preparedness of the sprint stories, the team maturity.

But the general guidelines that it takes

about four hours for a two-week sprint including the tasking out.

Again like I said,

then it depends on your preparedness.

Let's start off with some of the frequently asked questions about sprint planning.

So, what if your team members are taking PTOs,

or new people are joining or leaving the team,

do you need to update the velocity of the team?

The answer is generally no,

unless the people are going in bulk.

Like, for example, in holidays a lot of people are going.

So, in that case, you may want to update it.

But in most cases,

it's taken care of and generally you use the capacity to come in.

So, that optimally take care of the PTOs and who is available.

How do you handle interruptions?

So, let's say you are in the middle of the sprint,

and somebody says, "Oh,

this is really, really important and CEO want this to get done."

Now, do you just jump on,

you stop everything, and start working on that?

The recommendation is that you should involve your product owner

and to make sure that it either aligns with it,

or if he's going to put something into the sprint,

then you need to again evaluate if we can still meet the commitment.

So, generally the idea is to let your product owner know

and let the product owner decide if this should be part of the sprint or not.

Do you estimate defects?

My answer is no,

but teams do both things.

Sometimes they will estimate their defect and

include that in the estimate for the sprints.

But generally if there are defects,

the team will not be able to do the other stories,

so their velocity will go down,

and the next sprint they will ultimately take less work to start with.

So, my recommendation is not to estimate defects.

Either the team will reduce the number of defects or their velocity is going to go down,

and they will take less work.

What's the difference between velocity and capacity?

So, velocity is based on the story sizes whereas capacity is

what we calculate based on the availability of hours and days of individual team members.

How do you account for setup time when it's

a new project and when you're just getting started?

How do you account for time for setting your workstations and all those kind of thing?

There's a concept of iteration zero where all the developers can setup the workstations,

continuous integration server, version control.

So, all of these things are setup in that iteration zero.

One of the tip I give to people or teams is

that you should always take one or two stories,

very simple stories, to finish by the end of iteration zero.

So, even though the main focus is to setup

the continuous integration server and your workstations,

but then it provides focus to finish something by the iteration zero.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play