Agile Estimation and Planning

Loading...

En provenance du cours de University of Minnesota

Agile Software Development

134 notes

University of Minnesota

Agile Software Development

134 notes

Cours 2 sur 4 dans 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.

À partir de la leçon

Requirements and Planning

In this module we will learn about user stories and agile estimation and planning techniques.

Agile Estimation and Planning13:22

Estimation Styles and Process8:22

Release Planning7:26

Release Tracking4:13

Rencontrer les enseignants

Praveen Mittal
Adjunct Professor
College of Science and Engineering

In this lesson, we're going

to learn about what is the Agile Approach for Planning and Estimation.

Let's start with the Planning.

So in Agile Planning,

we do multi-level planning, which means,

like for a release level which means the release

could be for a quarter or for a couple of months,

then we do Attrition Planning,

which is every couple of weeks.

We do the planning, and then we do the daily planning.

The second concept in Agile Planning is less upfront but frequent.

So we don't do everything like lot of detail-level planning in the beginning,

but we do more frequent planning.

As you can see, we're planning every two weeks and everyday.

So we don't do lot of planning in the front but we are doing more frequently.

Then there is the concept of "Just enough, just in time."

which means, like for the Release Planning,

we don't go to the task level,

or we don't go to the very detail.

We stay at a very high level.

But then, when we go to the attrition level,

we will do Story Level Planning.

And then when we do the daily planning,

it would be again at the task level.

So, just enough, just in time.

And then the last concept is adapt and re-plan.

So as we learn new stuff, as things change,

we are open to change the plan,

and then move forward.

So in pictorially it moves from Gantt chart,

which has the very detailed plan ready up front in the beginning up to the task level,

to a Multi-level Planning where you have a Release-level Planning,

then Attrition planning, and then the daily planning.

Let's dig deeper into how this whole thing work.

So, let's say we have the product vision and we know what we want to build.

And so, based on that vision,

we're going to create a product backlog which will have

the ranked list of stories that we need to build.

Again, it's a starting point and it would change over time.

Or, we can have a story map that defines the product from a user perspective,

but tells everything that we need to build.

So from the product backlog,

or based on the story map,

we carve out a bunch of stories that we

want to build in a release, or we want to release those.

That becomes the release backlog,

and we do the Release Planning for that release.

Once we are done with Release Planning,

and we know it is what we want to build next,

then we break those release into multiples sprints,

or sometimes also call iterations,

and then we carve out a couple of stories from the release for that script.

And so that becomes the Sprint Backlog.

So again, then we start working on that part of the Sprint.

And then once that Sprint is done,

then we carve out another few stories,

the Sprint Two and N number of Sprints.

Within each Sprint, we actually create the task for each of those stories,

and then put them on the task board.

And then on a daily basis,

we get together and just say,

"Okay, what is the plan for today?

What task are we going to do today?"

So as you can see,

from Release Planning to Sprint Planning and then to the start-up,

so that is how Release Planning happens.

Let's talk about Agile Approach for Estimation.

So in Agile, we use these three concepts, Effort Versus Duration.

So we measure Effort or we estimate Effort and the Duration.

Accuracy Versus Precision.

We prefer Accuracy.

And then there are two ways to go about estimation,

either Relative or Absolute.

So we're going to talk about these concepts.

Effort Versus Duration.

So if I ask you or if I ask somebody to paint a deck,

the person may say,

"It'll take me three days."

And I might be surprised, "Oh, three days?"

And then he may provide me further details as to "Oh,

it will take me three days whole but I will

just need to do the cleaning or power wash on the first day.

I'm going to let it dry.

And then next day I'm going to do a couple coats of paint,

and then I will again let it dry.

And then on the third, I will do some final finishing touches."

So as you can see,

the effort is not three days,

it's the duration which was three days.

So in this case the duration was three days,

but the effort was the quarter day on the first day,

and then half a day to couple coats of paint,

and then again the quarter day for finishing touches.

So the effort was one day but the duration was three days.

And so what you will hear in Agile is you will hear this term call Ideal Days,

which is how many work days,

or sometimes they also call it Developer Days.

And those could be from eight to five,

or whatever it is a typical Developer Day.

How many work days will it take to complete the story if you work uninterrupted?

So that's the definition of Ideal Days,

and that's how we estimate Effort for stories.

The second concept is Accuracy over Precision.

So, to understand the difference between the two,

let's say that I have these eight stories,

and I ask somebody, "Hey,

go ahead and give me precise estimate for these stories."

So to get a precise estimate,

the developer has to dig deeper and find out exactly what they need to do.

And they have to spend a couple days just to find out

exactly what is involved in each of these stories,

and come up with this precise estimate,

like 2.7 days or 6.5 days,

5.2 days and so on.

Whereas, if I just want a rough idea,

and I want to prefer more accuracy or precision,

what I can do is I can just say,

"Here are the four buckets."

And I can ask the developer to put these eight stories into one of these three buckets.

I don't need the estimated 6.5 days or 4.1 days,

just dig the same stories,

and instead of estimating it precisely,

just put them in one of these four buckets.

In that case, the developer can quickly put these stories here,

and then 5.2 days,

when he or she will be estimating,

it's approximately 5 days, 4.1 days.

So, it will be pretty quick and they'll be

able to put these stories into these four buckets.

Now these are not precise estimates because they'll be one day's estimates,

three days' estimate, five days' and eight days',

but they are pretty accurate,

like it'll take one day or less,

it's three days or less, approximately five days,

and approximately eight days.

So that's the approach that we take in Agile.

And I just took four buckets,

but it's also called Estimation Scale.

But there are few popular scales that people generally use,

it's one, two, four, eight.

Sometimes they use Fibonacci series: one,

two, three, five, eight, 13.

As you will see that as the estimate become larger and larger,

the gap between the numbers increases.

And that is for a reason.

The reason is that the bigger the item,

more difficult it is to estimate,

and more unknowns are there,

more complex the work is,

and generally takes longer as the stories become bigger.

Or you can use five: one, five, 10,

20, or sometimes just the T-shirt sizing,

like Extra Small, Small, Medium, Large,

Extra Large, or just Small, Medium, Large.

You may asking, "What if I can't estimate?

I have a question and I can't estimate a story."

So for that reason, sometimes teams will also put a question mark as an option.

So if they don't know the story,

they'll just put a question mark on it.

And another question might be,

"How many buckets should I have? Should I have four buckets?

Should I have 10 buckets?

Should I have 20 buckets?"

Again, it depends.

If you have less buckets, it be faster estimation,

but it will be less precise.

If there are more buckets,

it's going to be slower estimate but it's going to be more precise.

And generally there is a diminishing return after a while,

the more precise you get.

So again it depends on it.

I would say stay four to five buckets.

The next concept we want to talk about is Relative Versus Absolute Sizing.

So I have a question for you: What do you think, approximately,

what's the area of the small box and the bigger box?

It might take a few minutes for you to get the absolute area for these two boxes,

but if I tell you that this box is one unit,

what do you think the size of the bigger boxes is?

It'll just take you a few seconds and you will say four unit.

Because we are really good at relative sizes,

we can say approximately this is four times the size of the small box.

So the same concept can be applied to Estimation.

And in Agile, both relative and Absolute Sizing is used,

and we will take some examples and see how it goes.

So in the Relative Sizing examples,

let's say Story A is one point.

And if I give you another Story and say it sounds like a five times the Story,

you'll give it five points.

Or sometimes people use arbitrary units, like apples.

So you'll say, "This story is five apples.

Okay, if this is five apples,

then this is 15 apples,

and this one is maybe 10 apples."

Or like I said,

T-shirt sizing: Small, Medium,

Large, or Extra Small and so on.

In the Absolute Sizing,

you will use exactly like,

"This will take one day,

B will take five days,

or this will take four hours,

and this will take two hours."

Now Absolute Sizing, as we said,

sometimes can take longer.

But if you're using buckets,

it doesn't take that long,

because you have only four or five buckets to sort the stories into.

So even if you're using Absolute Sizing,

if you're using buckets,

it doesn't take that long.

So if you put all of these concepts together,

generally there are two types of Estimation that you will

see in Agile Teams: one is the Relative Sizing using some arbitrary units,

mostly people use Story Points,

or they will use these Ideal Day Buckets.

So if you're using either of them,

they're both equally good.

But let's go through some of the pros and cons of each.

So if you're using a Story Point,

it's very difficult to get accustomed to because

it's really difficult to say, "Is this a Five Point?

What is Five Points?" Because you have to remember the scale.

And you have to understand,

you have to get used to that scale.

Whereas Ideal Day, it's pretty natural.

It's less than one day, it's less than five days and so on.

The Story Points, like I said,

Relative Sizing is really faster,

but the Ideal Day,

although I said tedious here,

but it is not as tedious if you're using like six buckets.

The problem that comes with Ideal Day is the my Ideal Days are not your Ideal Day issues.

Which means if you give the same story to an expert,

or a Senior Developer and a Junior Developer,

then the Junior Developer may say that, "Well,

I'm going to put this in less-than-eight or eight-days bucket."

Whereas the senior person may put it in the three-day bucket,

because for the senior developer it won't take that long.

But then if you use Relative Sizing,

a small is always going to be small, right?

Even for a Junior developer.

If there is a bigger story,

so they will put it in the large and the smaller story will go into the smaller bucket.

So that problem doesn't exist if you're using the Relative Sizing.

But the Story Point is very difficult to explain to the outside person.

Well, if a new team member joins, imagine,

and the team is estimating it and

somebody reads the story just says, "Yeah, this is five point."

The new person will say, "What?

What does this mean?"

Whereas in the Ideal Day bucket,

if a new developer comes,

if you say five days you get an idea,

he or she will get an idea what that means.

But one problem that people see and sometimes don't see,

depends on the management,

is with the Ideal Day,

is that suppose you estimated the story to be five Ideal Days,

and took you 10 days to build it because it's complex.

Then management will say,

"Why did it take that long?"

And this could result into a bad behavior or not a good environment in the team,

when they try to make the Ideal Days be the actual days that were spent on the story.

Whereas, if you use Relative Sizing,

management has no idea, "Okay,

this is a Five-point Story,

is going to take longer.

If it's a One-point Story, is going to take less."

How less and more,

they have not much of an idea.

So again, like I said,

both concept has pros and cons,

and different teams like different techniques,

but both techniques are used and are equally good.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play