Transitioning to agile means using different measurements. Using agile means looking at new metrics that matter to
the team and to management. These metrics matter because they focus on customer value.
One problem with status reporting is the team’s ability to predict completion or to use traffic light status to describe
the project. For instance, project leaders describe the project as “90% done.” At that point the team tries to integrate the
pieces into a product. The team discovers missing requirements or surprises, or finds that the product doesn’t integrate
The project is only partway done, and the traffic light status reporting does not reflect the real state. Too often, the
project team realizes it will need just as much time to complete the remainder of the project. For too many projects, the
team realizes they are—at most—10% done because of issues the team discovered.
The problem with predictive measurements is that they often do not reflect reality. It often happens that a project
status light is green up until 1 month before the release date; this is sometimes referred to as a watermelon project
(green on the outside, red on the inside). Oftentimes project status lights turn red with seemingly no warnings, because
there is no empirical data about the project until 1 month before the release date.
Metrics for agile projects contain meaningful information that provide a historical track record, because agile
projects deliver value (finished work) on a regular basis. Project teams can use such data for improved forecasts and
Surrogate measurements such as percent done are less useful than empirical measurements such as finished
features. See Section 4.10 for more information on value management. Agile helps teams see problems and issues so
the team can diagnose and address them.
In addition to quantitative measures, the team can consider collecting qualitative measures. Some of these qualitative
measures focus on practices the team has chosen and assess how well the team uses those practices, for example,
the business satisfaction with delivered features, the morale of the team; and anything else the team wants to track as
a qualitative measure.
��
61
5.4.1 AGILE TEAMS MEASURE RESULTS
Agile favors empirical and value-based measurements instead of
predictive measurements. Agile measures what the team delivers, not what
the team predicts it will deliver.
A team that is accustomed to having project baselines and estimates of
earned value and ROI might be puzzled about working on a project and not
managing to a baseline. Agile is based on working products of demonstrable
value to customers.
Baselines are often an artifact of attempted prediction. In agile, the team
limits its estimation to the next few weeks at most. In agile, if there is low
variability in the team’s work and if the team members are not multitasking,
the team’s capacity can become stable. This allows better prediction for the
next couple of weeks.
After the team completes work in iteration or flow, the team can replan.
Agile does not create the ability to do more work. However, there is evidence
that the smaller the chunk of work, the more likely people are to deliver it.
Software product development, like other knowledge work, is about
learning—learning while delivering value. Hardware development and
mechanical development are similar in the design parts of the project.
Learning takes place by experimenting, delivering small increments of
value, and getting feedback on what has been accomplished thus far. Many
other product development projects incorporate learning also.
Sponsors usually want to know
when the project will be done. Once
the team establishes a reliable
velocity (average stories or story
points per iteration) or the average
cycle time, the team can predict how
much longer the project will take.
As an example, if the team
averages 50 story points per
iteration, and the team estimates
there are about another 500 points
remaining, the team estimates it has
about 10 iterations remaining. As
the product owner refines the stories
remaining and as the team refines
its estimates, the project estimate
could go up or down, but the team
can provide an estimate.
If the team averages a cycle time
of three days per story and there are
30 remaining stories, the team would
have 90 business days remaining,
approximately 4 to 5 months.
Reflect the estimate variability
with hurricane-style charts, or some
other variability measure that the
sponsors will understand.
62
Section 5
Because learning is such a large part of the project, the team needs to balance uncertainty and provide value to the
customers. The team plans the next small part of the project. The team reports empirical data and replans further small
increments to manage the project uncertainty.
Some iteration-based projects use burndown charts to see where the project is going over time. Figure 5-1 shows an
example of a burndown chart where the team planned to deliver 37 story points. Story points rate the relative work, risk,
and complexity of a requirement or story. Many agile teams use story points to estimate effort. The dotted burndown
line is the plan. In Figure 5-1, the team can see by Day 3 that they are at risk for that delivery.
Do'stlaringiz bilan baham: 
