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
4.1.4: Estimates, Targets, and Commitments
Loading...
Del curso dictado por University of Alberta
Agile Planning for Software Products
885 calificaciones
De la lección
Module 1: Introduction to Planning
Welcome to the first module! In this module, you will be learning some basic principles that you will need for effective planning. You will start this module off with an introduction to planning. You will then learn about how planning, and the approach you take to planning, can reduce uncertainty in your project. We will then move onto learning how to breakdown a project into small, manageable pieces, and how to organize those pieces. Finally, we will go over the differences between estimates, targets, and commitments. Together, these lessons will build a good base for learning planning techniques at both the release and iteration level.
Conoce a los instructores
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[MUSIC]
I want to start off this lesson, by having you consider the sentence:
“I estimate that we can commit to a certain target date.”
It seems like it makes sense and
it's actually quite common in software development.
The terms estimate, target, and commitment are often thrown around loosely,
and sometimes used interchangeably.
But these terms are actually very different, and it's important, for
the sake of you and your development team, that you differentiate the terms.
Let's go through these terms individually.
An estimate is a guess for the time it will take for your development team to complete a task.
These should be based on some sort of data,
like previous times of similar tasks.
Estimates should also generally be a range because,
realistically, a precise hour or number of days is not going to be accurate.
Estimates should also not be negotiable, so
it's important that they're as accurate as they can be, they are what they are.
Let's look at an example.
Kirk is a product manager.
He approaches one of his developers that he works with, Liz.
He asks Liz how long it'll take her to develop a certain feature.
Kirk has worked with Liz in the past, and
he thinks it should take her about three hours, if she works hard.
Liz thinks to herself and decides to pad her estimate a bit so
that she can relax at work.
She tells Kirk it will take her nine hours to develop that feature.
Kirk tells Liz that he thought it would take her only three hours and
asks her to split the difference.
Liz agrees and Kirk records six hours as the estimate.
This is not how it should occur.
Estimates should be realistic.
That's why it's important to base estimates on prior work.
You could accurately estimate that it would take Liz between three and
nine hours to complete the task.
You are the product manager working with a small development team.
You are talking to the developers to gather time estimates
to help in scoping a product.
You talk with one developer, Greg,
you ask him how long it will take him to write tests for a particular feature.
You guess that it'll take him five hours. Greg has just written tests for
a similar feature and it took him six hours.
He wants to give himself some cushion room, so
he tells you it will take him ten hours.
You think that maybe you could split the difference and write down seven and
a half hours.
What would be the most accurate time estimate for this task?
A. 5 hours, B. 6 hours C. 10 hours.
Or D. 7.5 hours.
As we've said before, you want to base your time estimates on previous,
similar work.
It's the most accurate way to get estimates,
especially if done by the same person.
Therefore, answer B is correct.
When estimates are based upon how long a developer wants to complete their task, or
based on how long a manager wants the developer to complete the task,
you risk over or under estimating the time it'll actually take.
Answers A and C are incorrect.
And again, estimates should not be a negotiation.
So you should not split the difference.
Therefore, answer D is also incorrect.
Let's now take a look at the term: target.
A target is a point in the schedule to meet.
This is almost an ideal deadline.
A target should also not be negotiated.
Examples of a target could be the end of a sprint or the release date.
These targets, once decided, must be adhered to.
Target dates are used in arranging product promotions, and are usually contractual.
Adhering to these target dates is very important for
client satisfaction, as well as product success.
If estimates and
targets are non-negotiable, how do you negotiate what will get developed?
That's where commitments come into play.
Commitments are where negotiations happen based on your estimates and targets.
You can negotiate what you can commit to.
You are going to have to constantly ask yourself how do I compromise on what
the development team will commit to doing, based on their estimates and
the time constraints?
A commitment is what you are agreeing to deliver.
It is very common that estimates are automatically
converted into commitments and targets.
If you are asked how long it is going to take to make a product and
you estimate seven months then that seven months becomes your commitment.
And the date, seven months down the line becomes your target.
Again, this is not how it should work.
Let's look at this in an example.
Say I was babysitting for a family.
I asked the parents when they would be home.
They say they should be back around midnight.
This is their estimate.
If I were to ask them for a commitment, in the sense that,
if they are not home at that time, I'm going to triple my baby-sitting fees.
They might say 12:30, to give themselves some buffer time
in case they want to stay longer, or the commute takes longer than expected.
Ideally you want to discuss estimates with your development team and
come up with some accurate numbers.
You'll also want to talk to your client about target dates.
Then based on these items,
create commitments with your development team and your client.
You are meeting with your client and development team.
You have already talked to your development team, and
they have determined that, based on their previous work, this project should take
them about eight months to complete with all the features that the client wants.
The client wants the product to be completed before the holidays, so
she suggests a release date that is seven months away.
Together, you all agree on a scope that's about five months of work.
Six months later, your development team has completed
all the features that were originally agreed upon.
Which amount of time would be the commitment?
A. 8 months, B. 7 months, C. 6 months, or D. 5 months.
When your development team determined that it would take them eight months of work
to complete all the features that was an estimate.
It was based on their previous work.
Answer A is incorrect.
The release date that was scheduled for
seven months in the future would be the target.
Therefore answer B is incorrect.
The six months that it actually took your team to develop all the features
is not an estimate target or commitment for this scenario.
However, you could use this development time to create estimates for
future projects.
Answer C is also incorrect.
Your development team and
client negotiated the scope that contained about five months of work.
That would be the commitment.
It was what your team actually committed to developing.
Therefore, answer D is the correct answer.
Remember that estimates and targets, once set, are non-negotiable.
What you can negotiate is what you can commit to for the scope of the project.
Be careful not to let your estimates become commitments or targets.
Keep these items separate, and make sure that your team and
your client does as well.
It will keep your scope from getting too large,
as well as it will make sure that you can actually meet target dates.
Let's see how those in the industry deal with large projects involving many people.
[MUSIC]
>> One of the techniques that our project managers use to manage multiple projects
is the use of what we call Streams.
So I might create streams of activities or streams of projects where we would assign
a project coordinator or project manager underneath that program manager.
Really understanding what is required within each of
those projects, what the deliverables are.
So that we can roll those up and
understand the interdependencies at a program level.
Typically multiple projects are related to one another.
When they are related to one another, understanding how they
actually are interdependent in terms of predecessors and
successors, in terms of what needs to be done first and what needs to be done next.
So rolling that up into an overall
schedule helps our project managers better understand how they inter-relate.
As well we might use Work Breakdown Structures to understand all the work
packages that are required that might inter-relate.
[MUSIC]
>> We use a few different mediums to report to our clients, our managers,
our executives, amongst our projects.
Different communication methods including status reports.
Different meeting minutes.
We use actions logs.
We use risk registers as well.
One of the key pieces that we advise our project managers and
product managers is to ensure we also use informal communication.
Making sure that we are not providing any surprises in any of our documentation.
And so sort of having that ad hoc kind of drive by communication,
making sure we're socializing different things, risk perhaps or
issues that may arise to our stakeholders, especially the executive team.
That executive team may or
may not always have the time to actually read some of the documentation, and
read status reports and risk registers and things that have a lot of detail.
So how are you gonna create new communication mediums
to actually tailor to some of those more busy audiences and stakeholders?
So for us we use a no-surprise philosophy, and we ensure that we have some of those
drive-bys socialized different ideas verbally or over the phone.
In terms of agile practices, and some of the challenges that we face,
you know we're a virtual community across several branches across North America.
And so, one of the challenges that we face is really understanding and
managing virtual teams.
So, how do we collaborate?
How do we do things like scrum meetings when not everybody is physically present?
And so that collaboration, and that unification across
the teams across different locations, is a little bit of a challenge for us.
[MUSIC]
>> Todd Birzer, who's a consultant with Kevolve Product Management,
has a great way of defining this.
He looks a four different areas that product managers are responsible for.
So the four are: market intelligence, product strategy,
product development, and lifecycle management.
So briefly with market intelligence you are researching what's going on in
the market, what's popular, what are the solutions that people are using,
what type of monetization models are being used, what are our customers or
potential customers doing, and what technology is available for
us to use out there that will help solve problems.
With product strategy, we're looking at monetization models and a fit
between the context of where we're doing development and the technology
capabilities, and then mostly, most importantly is defining a differentiator.
How are we different from other people?
And how do we solve a problem for real people who are out
wandering around in the world who need our help with technology?
And then from there, when we have that nailed down,
we look at starting to road map.
So coming out with a plan of how we're going to build something.
What that should look like.
Well, there's a classic agency problem,
which means different people are awarded differently.
They're looking for different things out of a product, and
in software development, it's incredibly resource-intensive,
and it doesn't always quickly as these groups would like.
[MUSIC]
That's incredibly difficult.
It's a lot of time spent talking to people, finding out what their needs are,
finding out what their perspective is and finding out common ground.
So it can be reasonably straightforward with a new venture, where
people, a lot of the ideas are fresh and there is a lot of a shared experience.
But typically the different groups have very different goals and
different personalities in working styles and
they require different environments and context to do their work.
So they may use different language.
So technical people will use technical jargon and
so that can be off putting or misunderstood by other groups.
So there's often a lot of what on the surface feels like conflict. So
a lot of the work that I do is I try to find common ground.
So on some projects I interview people and I do affinity maps.
I'll take out different colored markers and get out the thesaurus and
I'll look at nouns and verbs and adjectives and highlight them and
then say okay you're actually saying the same thing.
And finding that common ground, that commonality.
The other thing that's important there is when there's a focus and
a differentiator, and reminding people why we're in business.
What's the problem that we're solving for a particular particular user.
If we can bring that 40,000 foot view into our conversations to help set the context,
that really helps keep people focused.
>> In the next module, Bradley is going to teach you how to create accurate estimates
and how you can use these estimates to organize tasks for a project release.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
