Download Applied Software Project Management

Applied Software Project
Management
Estimation
http://www.stellman-greene.com
1
What is estimation?
• The project manager must set expectations about
the time required to complete the software among
the stakeholders, the team, and the organization’s
management.
• If those expectations are not realistic from the
beginning of the project, the stakeholders will not
trust the team or the project manager.
http://www.stellman-greene.com
2
Elements of a Sound Estimate
• To generate a sound estimate, a project manager
must have:
– A work breakdown structure (WBS) (A detailed specs helps
you to do that) or a list of tasks which, if completed, will
produce the final product
– An effort estimate for each task
– A list of assumptions which were necessary for making the
estimate
– Consensus among the project team that the estimate is
accurate
http://www.stellman-greene.com
3
Assumptions Make Estimates More
Accurate
• Team members make assumptions about the work to
be done in order to deal with incomplete information
– Any time an estimate must be based on a decision that has
not yet been made, team members can assume the
answer for the sake of the estimate
– Assumptions must be written down so that if they prove to
be incorrect and cause the estimate to be inaccurate,
everyone understands what happened
– Assumptions bring the team together very early on in the
project so they can make progress on important decisions
that will affect development
http://www.stellman-greene.com
4
Wideband Delphi
• Wideband Delphi is a process that a team can
use to generate an estimate
– The project manager chooses an estimation team,
and gains consensus among that team on the
results
– Wideband Delphi is a repeatable estimation
process because it consists of a straightforward
set of steps that can be performed the same way
each time
http://www.stellman-greene.com
5
The Wideband Delphi Process
• Step 1: Choose the team
– The project manager selects the estimation team
and a moderator. The team should consist of 3 to
7 project team members.
• The moderator should be familiar with the Delphi
process, but should not have a stake in the outcome of
the session if possible.
• If possible, the project manager should not be the
moderator because he should ideally be part of the
estimation team.
http://www.stellman-greene.com
6
The Wideband Delphi Process
• Step 2: Kickoff Meeting
– The project manager must make sure that each team
member understands the Delphi process, has read the
vision and scope document and any other documentation,
and is familiar with the project background and needs.
– The team brainstorms and writes down assumptions.
– The team generates a WBS with 10-20 tasks.
– The team agrees on a unit of estimation.
http://www.stellman-greene.com
7
The Wideband Delphi Process
• Step 3: Individual Preparation
– Each team member independently generates a set
of preparation results.
– For each task, the team member writes down an
estimate for the effort required to complete the
task, and any additional assumptions he needed
to make in order to generate the estimate.
http://www.stellman-greene.com
8
The Wideband Delphi Process
• Step 4: Estimation Session
– During the estimation session, the team comes to a
consensus on the effort required for each task in the WBS.
– Each team member fills out an estimation form which
contains his estimates.
– The rest of the estimation session is divided into rounds
during which each estimation team member revises her
estimates based on a group discussion. Individual numbers
are not dicsussed.
http://www.stellman-greene.com
9
The Wideband Delphi Process
• Step 4: Estimation Session (continued)
– The moderator collects the estimation forms and plots
the sum of the effort from each form on a line:
http://www.stellman-greene.com
10
The Wideband Delphi Process
• Step 4: Estimation Session (continued)
– The team resolves any issues or disagreements that are brought up.
• Individual estimate times are not discussed. These disagreements are usually
about the tasks themselves. Disagreements are often resolved by adding
assumptions.
– The estimators all revise their individual estimates. The moderator
updates the plot with the new total:
http://www.stellman-greene.com
11
The Wideband Delphi Process
• Step 4: Estimation Session (continued):
– The moderator leads the team through several rounds of estimates to
gain consensus on the estimates. The estimation session continues
until the estimates converge or the team is unwilling to revise
estimates.
• Step 5: Assemble Tasks
– The project manager works with the team to collect the estimates
from the team members at the end of the meeting and compiles the
final task list, estimates and assumptions.
• Step 6: Review Results
– The project manager reviews the final task list with the estimation
team.
http://www.stellman-greene.com
12
Other Estimation Techniques
• PROBE, or Proxy Based Estimating
– PROBE is based on the idea that if an engineer is building a component similar
to one he built previously, then it will take about the same effort as it did in
the past.
– Individual engineers use a database to maintain a history of the effort they
have put into their past projects.
– A formula based on linear regression is used to calculate the estimate for each
task from this history.
• COCOMO II
– In Constructive Cost Model, or COCOMO, projects are summarized using a set
of variables that must be provided as input for a model that is based on the
results of a large number of projects across the industry.
– The output of the model is a set of size and effort estimates that can be
developed into a project schedule.
http://www.stellman-greene.com
13
Other Estimation Techniques
• The Planning Game
– The Planning Game is the software project planning method from
Extreme Programming (XP), a lightweight development methodology
developed by Kent Beck in the 1990s at Chrysler.
– It is a full planning process that combines estimation with identifying
the scope of the project and the tasks required to complete the
software.
– The Planning Game is highly iterative. The scope is established by
having Development and Business work together to interactively write
“user stories” written on index cards to describe the scope. Each story
is given an estimate of 1, 2 or 3 weeks. This process is repeated
continuously throughout the project.
http://www.stellman-greene.com
14
Conflicts
• Developers always prefer higher estimate
• Managers always prefer quick delivery
• How to avoid the conflicts?
– KISS (work the estimates with the developers)
Padded estimate generate distrust
• Be aware
– Software engineering often overoptimistic by
nature
– When no deep thinking is done, it is easy to ignore
problems that may come up later
– It is very tempting to make padded estimate since
they lead to longer schedule and less pressure
Planning poker
• Planning Poker is a consensus-based estimation
technique for estimating, mostly used to estimate
effort or relative size of tasks in software
development. It is a variation of the Wideband
Delphi method. It is most commonly used in agile
software development, in particular the Extreme
Programming methodology.
• The method was first described by James
Grenning[1] in 2002 and later popularized by Mike
Cohn in the book Agile Estimating and Planning[2].
Planning poker card
• A typical deck has cards showing the Fibonacci sequence
including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks
use similar progressions.
Procedure
1.
2.
3.
4.
5.
6.
7.
8.
9.
At the estimation meeting, each estimator is given one deck of the cards. All decks have
identical sets of cards in them.
The meeting proceeds as follows:
A Moderator, who will not play, chairs the meeting, supported and advised by the Project
Manager.
The most knowledgeable developer for a given feature provides a short overview. The
team is given an opportunity to ask questions and discuss to clarify assumptions and risks.
A summary of the discussion is recorded by the Project Manager.
Each individual lays a card face down representing their estimate. Units used vary - they
can be days duration, ideal days or story points. During discussion, numbers must not be
mentioned at all in relation to feature size to avoid anchoring.
Everyone calls their cards simultaneously by turning them over.
People with high estimates and low estimates are given a soap box to offer their
justification for their estimate and then discussion continues.
Repeat the estimation process until a consensus is reached. The developer who was likely
to own the deliverable has a large portion of the "consensus vote", although the
Moderator can negotiate the consensus.
An egg timer is used to ensure that discussion is structured; the Moderator or the Project
Manager may at any point turn over the egg timer and when it runs out all discussion must
cease and another round of poker is played. The structure in the conversation is reintroduced by the soap boxes.
Avoid anchoring
• Anchoring occurs when a team openly discuss
their estimates. A team normally has a mix of
conservative and impulsive estimators and
there may be people who have agendas;
developers are likely to want as much time as
they can have to do the job and the product
owner or customer is likely to want it as
quickly as possible.
Why anchor should be avoided?
•
•
•
The estimate becomes anchored when the product owner says something like, "I
think this is an easy job, I can't see it taking longer than a couple of weeks", or
when the developer says something like, "I think we need to be very careful,
clearing up the issues we've had in the back end could take months".
Whoever starts the estimating conversation with, "I think it's 50 days" immediately
has an impact on the thinking of the other team members; their estimates have
been anchored, i.e. they are all now likely to make at least a subconscious
reference to the number 50 in their own estimates. Those who were thinking 100
days are likely to reduce and those who thought 10 are likely to raise. This
becomes a particular problem if the 50 is spoken by an influential member of the
team when the rest of the team are predominantly thinking higher or lower.
Because the remainder of the team have been anchored they may consciously or
otherwise fail to express their original unity; in fact they may fail to even discover
that they were thinking the same thing. This can be dangerous, resulting in
estimates that are influenced by agendas or individual opinions that are not
focussed on getting the job done right.
• Planning poker exposes the potentially influential
team member as being isolated in his or her
opinion among the group. It then demands that
she or he argue the case against the prevailing
opinion. If a group is able to express its unity in
this manner they are more likely to have faith in
their original estimates. If the influential person
has a good case to argue everyone will see sense
and follow, but at least the rest of the team won't
have been anchored; instead they will have
listened to reason.
4 reasons why estimating is good for your
project
•
•
•
•
•
For estimation, planning poker is by far the best mechanism we’ve used for estimation to
date, and the accumulated estimates usually turns out quite realistic.
You’ll achieve sprint goals. History shows that we’re spending from one-third to twice the
estimated time for each task(!) That does not sound all that great, but remember that these
are the extremes. The most important, however, is that for the sum of tasks the estimates are
usually quite accurate, which means that the sprint will be finished on-time, which is the goal
of this procedure.
Discuss only the important. The mechanism for picking the right two people to discuss (the
one with the low, and the one with the high estimate, if more than marginally different) leads
to both efficient and effective resolution of the differences of opinion and understanding of a
task.
Improves the specifications. Estimation reveals lacking task-specifications. When people are
way off to either side in their estimates, the triggered discussion will resolve the weaknesses
in the specification that caused different estimates, and the specification must be detailed
accordingly.
The estimate tells you something about the task. Estimation adds another level of
description to a task in and of itself. If a task “Create customer list for product X” is estimated
at 1 hour, you know it’s not about developing a fancy application for it. Whipping up a textfile or installing a wiki might be the solution you’re looking for. Estimation is time-boxing and
constraining the solution. Constraints yields creative and effective solutions.