4.2.1: Story Points

Loading...

来自 University of Alberta 的课程

Agile Planning for Software Products

918 个评分

University of Alberta

Agile Planning for Software Products

918 个评分

课程 4（共 6 门，Specialization Software Product Management）

This course covers the techniques required to break down and map requirements into plans that will ultimately drive software production. Upon successful completion of this course, you will be able to: - Create effective plans for software development - Map user requirements to developer tasks - Assess and plan for project risks - Apply velocity-driven planning techniques - Generate work estimates for software products

从本节课中

Module 2: Project Planning

Welcome to module 2! Now that you’ve gotten your feet wet with general principles in project planning, let’s talk about some specific ways that you can use to implement those techniques. We’ll first discuss the concepts of story points and velocity, then move into how time boxing can be used to improve your project efficiency. We’ll then introduce the Gantt chart, a basic tried and true method of visualizing project tasks. We’ll finish off with techniques for planning your project at a release level, which will set the stage for iteration planning in the next module.

4.2.1: Story Points5:24

4.2.1A: Story Points10:59

与讲师见面

Kenny Wong
Associate Professor
Computing Science, Faculty of Science

[MUSIC]

Welcome to the next module on Agile Planning for Software Products.

In the last module, Morgan introduced some of the core concepts in planning,

like uncertainty space, how to break down work and

the difference between estimates, targets and commitments.

In this module, I'm going to talk about story points and velocity and

then move into some techniques for turning these estimates into tangible plans.

In the last lesson, Morgan talked about estimates, targets and commitments.

Here's a refresher.

A task estimate is an approximation of how long a task will take.

These are made by the developers who expect to work on the task that is

being estimated.

The estimates should be based on previous work.

They're non negotiable since they're only figures of how long work will take,

not commitments to when the work will be done.

A target is a deadline to be met.

Targets are usually set externally to the development team.

They're also non-negotiable, since other parties may depend on the dates.

Finally, commitments are real,

enforced work to which the development team commits.

They outline exactly what work will be completed at what time.

They're based off target deadlines and realistic estimates.

Commitments are the schedules by which a project is determined and

they're negotiated between the client and the development team.

Project commitments are governed by targets and estimates.

Targets are specific dates and estimates give commitments some realistic grounding.

Without estimates on how much time work will take,

commitments could be made that are not realistic by the target dates.

I just recapped what the difference is between an estimate, a target and

a commitment.

Which of these terms describes a deadline set externally to the development

team that must be met?

A. estimate.

B. target or C. commitment.

The correct answer is B, target.

Targets are dates that are set externally to the development team and must be met.

Commitments on the other hand are negotiable, where targets are not.

How do we create good estimates?

Well, Morgan mentioned in the previous lesson

that a developer should base their estimates on the amount of

time it has taken to implement similar functionality in the past.

She talked about a few different scenarios in which software developers gave time

estimates usually padded a bit to give the developer some breathing room, but

why is this?

What makes the software developer feel they have to pad their work estimates to

begin with?

Well, what often happens is that managers mistake developers

estimates as commitments.

Developers know this, they also know that their estimates may be way off.

In order to protect themselves from committing to something they might not

be able to uphold, the developer gives themselves a little bit of breathing room.

They pad out their estimate.

So a task that took four hours to complete in the past

is now being estimated to be completed in ten hours.

Of course, managers know this too.

They know when an estimate seems unreasonable.

It's no surprise then,

that managers end up negotiating these estimates with the developers.

Now, a ten-hour estimate is whittled down to a six-hour estimate.

They're compromising on the estimates, which should be absolute.

Organizationally, it doesn't make much sense.

Wouldn't it be better if you could just make an estimate

without it sounding like a commitment?

One of the problems here is that time is often used as a unit of measurement for

work estimates.

That's to say that each estimate is measured in hours.

It takes five hours to do this, one hour to do that.

Naturally, you might think that if a standard work day has eight hours,

you can complete one five-hour task and about three one hour tasks.

What ends up happening naturally is developers and

product managers begin to associate time estimates with working hours.

This makes it really easy to mistake the estimate for a commitment.

So how do we fix this?

Well, one method that's often used in the industry is the Story Point.

I just talked about some of the problems with estimating work on software projects.

Which of the following is the most common problem with work estimates

when they are estimated using hours?

A. Estimates should be made using minutes, not hours.

B. Time-based estimates can be misunderstood as commitments.

C. Software developers are bad at estimating time.

Or D. Estimates should be made using days not hours.

The correct answer is B,

time-based estimates can be misunderstood as commitments.

Story points are what we aim to use instead of time units.

Let's talk about Story Points some more.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2018 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取