Johanna Rothman Agile Team Measurements Chapter 12 Copyright © 2017

“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

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

Understanding Burndowns and Burnups Charts Ideal Line

Another way to provide the same information Ideal Line

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.”

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

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

“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”

Iteration Contents Defects Changes Features Iterations 12 10 8 6 4 2 Defects Changes Features 2 3 4 5 6 7 8 9 10 11 12 Iterations

“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?

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

Cumulative Flow for Entire Project

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

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

Times added to see accumulated Cycle Time Team 1 Kanban Board

Table 10: One Team’s Cycle Time

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”

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

“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”

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

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”

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

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.”

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

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.”