1. Johanna Rothman Agile Team Measurements Chapter 12
Copyright © 2017

2. “Agile Approaches”
“… provide a team the chances to measure what it has finished and what’s in progress (WIP), not what it anticipates doing” Although, the SCRUM “approach” requires collaboration with a Product Owner in order to identify the Features and the “user needs…” associated with each feature The “user needs” are in the form of “stories” … which are articulated through the 3-C’s process The Card specifying the use story Conversations to understand how the stories are to provide value to the user Confirmation that the Feature stories are understood and that definition of final product acceptance criteria

3. Team members learn from measuring their completed work
Charts used to understand what has been completed and how much remains:
Feature or story burnups to see feature progress
Feature charts to show what’s done, what’s added, and remaining features
Iteration contents to see what the team did, not just what they planned
Cumulative flow to see the WIP
Cycle time to see how long things take
Defect escapes and bounce-back to understand how defects might affect the team in the future

4. Understanding Burndowns and Burnups Charts
Ideal Line

5. Another way to provide the same information
Ideal Line

6. Cumulative Story Points Completed Hockey Stick
Steady Progress
“Measuring Points is not necessarily measuring progress. Points represent work. Stories are progress. To see progress, measure finished stories.”

7. Stories are estimated… Planning Poker … estimating the number of story points is the team’s attempt at “sizing the work” for each iteration The sprint is estimated to be sufficient to complete a fixed number of story points Stories are selected … the Sprint is “filled” with a number of points less than or equal to the team’s estimate of the amount of work that can be completed in each Sprint… … end of Sprint Retrospectives assess and modify as needed

8. Questions when expected progress is not being made
What might be the causes:
Everyone takes his or her own story at the start of the iteration
People get interrupted by other work that the team did not anticipate
The story was much more difficult that the team anticipated (and estimated)
Team members perform asynchronous code reviews…
… they have no collaborative commitment to review each other’s work

9. “Iteration content shows what the team completed”
To estimate the work ahead… “How much can we commit to for this iteration?” Example “ … a team can deliver nine features plus or minus a couple of defects … In addition the team takes changes in the form of urgent work from the support queue”

10. Iteration Contents Defects Changes Features Iterations 12 10 8 6 4 2
Defects
Changes
Features
Iterations

11. “How much can we commit to for this iteration”
The problems:
“The team estimates that it can do more work that it really can, so the team “pushes” to complete more work
The Product Owner substitutes one story of the “same” size for another story after the iteration starts.
The team does not find defects as soon as the team creates a defect, because to the rush to “finish” work.”
How do you imagine that the “developers” are doing their work?

12. Cumulative Flow shows Where the Work Is
“If you have only used Gannt charts or a SCRUM board*, you may never have seen where the work in a project is The Cumulative Flow chart shows how much work is in what state.” The Product Owner along with the team develops and maintains the Product Backlog … which includes all Features and the user stories for each Feature in priority order (the order in which the work will be done) The team, in collaboration with the Product Owner, provides the story point estimates for all the stories At the end of each Sprint, the work is assessed, changes identified as needed, and the Feature story-work identified for the next Sprint

13. Cumulative Flow for Entire Project

14. Cycle Time & Lead Time
Cycle Time The duration of time from when you put a card/story in the 1st in-progress column until you mark the card/story “done” Cycle time measures the time the team works on the story Lead Time The duration of time from when a card/story goes onto the backlog until you release the feature to the customer… the entire time from Product Backlog to Sprint Backlog to done and to customer use

15. Cycle time from the time you start a task until you
Possible Kanban Board
Cycle time from the time you start a task until you
complete it
Deliver to customer
Lead time: from the time you put it on the board until you deliver it

16. Times added to see accumulated Cycle Time
Team 1 Kanban Board

17. Table 10: One Team’s Cycle Time

18. Team 1 Kanban Board The Board, as is, does not reflect the Team’s flow
Develop and
Unit test In
Progress
Integrate
UX fixes
Check with UX
Ready
Dev
Done
System
Test
Done 8 3 2
The Board, as is, does not reflect the Team’s flow
Times omitted from “Check with UX”, “Integrate UX fixes, “Dev Done”

19. End of Sprint Retrospective
At the end of a Sprint, the team “knows” how many stories were “Done” … this also means they know how many Story Points were “Done” The team’s retrospective allows the team to know the number of Story Points actually “Done” versus the team’s estimated Sprint “capacity” of Story Points … This allows the team to compare the estimated Sprint “capacity” with the actual Sprint “capacity” achieved … indicating whether the estimated Sprint “capacity” should be changed

20. “Measure Cost to Fix a Defect”
“The software-engineering literature” refers to exponential costs through the life cycle to fix defects Cost of 1 in requirements, 10x in analysis, 100x in coding, 1,000x in testing, and 10,000x in post release” Rothman’s “experience… it does cost more, but not nearly that much”

21. Week 28 delivery with 60 “open” defects … not an Agile outcome
Measure the Defect Cumulative Flow graph… evidence of not a “Successful Agile Project” (nothing in the “Done” state)
Defects
Week
Week 28 delivery with 60 “open” defects … not an Agile outcome

22. Fault Feedback Ratio
The ratio of rejected fixes to total fixes Rothman’s experience is that “an FFR of more than 10% says the developers don’t make enough progress on finding and fixing problems” A less than “agile” approach Discuss the defects and their causes during the retrospective… if there is one …meaning that work is not “done” at the end of the sprint …probably no operational definition of “done”

23. Team-Measurement Traps
“Measuring team-level work can lead to gaming the measurements…”
(the culture makes this a “logical” option)
The team measures points instead of features
Story Points should indicate the estimated work required
The team doesn’t measure as it proceeds

24. TRAP: “People want to measure Points instead of Features”
“You’ve tried suggesting the team measure features completed…” Rothman’s suggestions: “… measure features and stories on the same graph … showing that one point is not a story” “Have the team work with the Product Owner to make sure all the stories are one-day stories (or smaller)” “… use cycle time and cumulative flow to estimate how long work will take and how much work is in progress” “The more you can help the team become a cohesive team, the more they will want to see the stories move across the board.”

25. TRAP: “The team waits to measure”
The team didn’t update its board on a regular basis…
The team didn’t update it measurements
The “Scrum Master” asked everyone what they had done during the entire iteration and then he or she updated the measurements
(clearly, not a “servant leader” but a “do it my leader”)
Rothman’s view of the role and responsibility of the “Scrum Master” as well as the “Product Owner” is not the same as the specified role in the Scrum development methodology

26. In conclusion… last page
“Teams can see their WIP when they create and use their own boards… and team members can see if they are making progress … and adapt as needed during the Sprint. The more often teams measure their progress, the more likely they are to create small stories so they can see their progress.”