Metrics Flashcards Preview

PMI-ACP > Metrics > Flashcards

Flashcards in Metrics Deck (25)
Loading flashcards...
1
Q

Overview of velocity

A

Extremely simple, powerful method for accurately measuring the rate at which teams consistently deliver business value.
Simply add up the estimates of the features (user stories, requirements, backlog items, etc.) successfully delivered in an iteration.

2
Q

Throughput

A

Throughput

3
Q

productivity

A

productivity

4
Q

cycle time

A

1) time between two successive deliveries
2) 34 enters the Deployed stage on day 11, then two days after, the next story– Story 37–enters the Deployed stage; cycle time equals 2 days (day 13 – day 11).

5
Q

lead time

A

1) time between the initiation and delivery of a User Story
2) Story enters the Deployed stage minus the time the story has entered the Backlog stage.
3) Story 34 has entered the Backlog in day 4, and enters the Deployed stage on day 11; lead time equals 7 days (day 11- day 4).

6
Q

EVM for agile projects

A

1) Establish baseline
2) Measure progress at defined boundaries
3) Current iteration number.
4) Number of story points actually completed.
5) Number of story points added to or removed from the release.
6) Actual Cost in dollars or hours. It is critical that the actual cost amount used reflects the cost needed to generate the completed story points.

7
Q

Escaping defects

A

1) should then be treated as ranked backlog work items
2) Watch the defect backlog as part of the project metrics
3) A growing defect backlog is a key indicator that the team is taking on more new work than it can handle
4) requiring more collaboration between Dev and Quality Engineers and early testing
5) Drop the number of new items the team works on until the escaping defects are well managed or eliminated.

8
Q

Approved iterations

A

approved iterations

9
Q

work in progress

A

work in progress

10
Q

Why is Velocity Important in Agile

A

After you do a few iterations, you will become better at estimating and your velocity should start to stabilize. With a stable velocity, planning releases and iterations becomes much easier. Management and the business are also loads happier as you are delivering standard size iterations with less surprises.

11
Q

How is the first iteration’s velocity estimated?

A

1) one-third of available time if estimating in ideal programmer time
2) If underestimated, velocity in the first iteration will rise as new features are included;
3) if overestimated, velocity will decrease as features are removed.

12
Q

Should velocity be accumulated across teams or projects?

A

1) Velocity is very much a localized measure
2) different team members with different team ‘personalities’, projects typically possess unique characteristics in terms of estimating techniques, detail process, technology, customer involvement

13
Q

What if velocity fluctuates?

A

1) Velocity will typically fluctuate within a reasonable range, which is perfectly fine.
2) If velocity fluctuates widely for more than one or two iterations, the team may need to re-estimate and/or renegotiate the release plan.

14
Q

How do I estimate velocity if project teams change size?

A

1) Velocity relies on team consistency in order to be most valuable.
2) It will only take the length of the next iteration to understand better what the team can deliver and thus their new velocity.

15
Q

Does maximum velocity mean maximum productivity?

A

1) Absolutely not.
2) In an attempt to maximize velocity, a team may in fact achieve the opposite.
3) there will be a negative long-term impact.
4) The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.

16
Q

How do we measure velocity if our iteration lengths change?

A

1) A fixed iteration length helps drive the reliable rhythm of a project.
2) Without this rhythm, you are constant revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results
3) adapt iteration dates or velocity accordingly

17
Q

Agile resource utilization

A

1) Capacity (individual, team) -during iteration planning
2) Estimated
3) Actual (recorded before standup meeting)
4) Performance (compare capacity vs actual)

18
Q

Estimated utilization

A

1) Capacity vs Estimated (iteration level)
2) E=64 hrs, C = 60hrs
3) utilization = E / C = 106.67%

19
Q

Actual utilization

A

1) Actual 55hrs
2) estimate 64hrs
3) capacity 60hrs
4) Actual utilization = actual / capacity = 91.67%

20
Q

three categories of defects

A

1) Defects found and fixed in the iteration
2) defects accepted by PO
3) defects that escapted

21
Q

Defect detection rate

A

1) No, of defects per project iteration
2) correlated with velocity
3) drop in velocity & rise in defect detection rate should trigger an alarm
4) low rate is not better than a higher one

22
Q

Defect closure rate

A

1) amount of defects fixed and closed per iteration
2) should be equal to defect detection rate
3) if

23
Q

Total vs closed defects

A

1) should be as low as possible

2) indicates velocity and burn rate are reliable indicators

24
Q

A healthy agile project

A

1) Stable velocity and burn rate
2) high defect detection rate
3) low total vs closed defects gap

25
Q

Agile approved iterations

A

1) approval is documented
2) by PO or customer
3) after passing definition of done (before end of iteration)
4) sometimes after end of iteration
5) document guidelines and criteria