Scrum Project Health Standards


Published on

A basic set of Scrum Metrics to start your agile adoption off with.

Published in: Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • To-Do Hours enable us to address the question of “What is the estimated work remaining for the Sprint?” Being able to answer this question on a daily basis empowers The IT Organization to forecast any potential adjustments to its initial Project Delivery estimates/commitments. Since this information is at a micro-level (i.e. Sprint Focus), it will primarily serve as a conversation initiator on Planning for the entire scope of the Project.Without accurate To-Do Hours, Scrum Masters cannot generate Sprint Burn Down reports that reflect the true state of the Sprint
  • Tracking Effort provides the foundation for calculating Earned Value (EV), so Agile EV calculations like the following can be derived: Schedule Variance, Cost Variance, Story Points Added and Complete, Story Points Added and Incomplete, etc. If we opt to introduce Effort as a Standard, it will make sense to involve Finance in our early discussions on the application of this data. For example, 2 Contract Developers working on a Two Week Sprint, record a total of 156 hours worth of Effort; however, they only bill PCH for 90 hours, so does The Organization want to use Effort, the Billing Amount, or both to calculate the ROI of the project? From, an Team Member’s perspective, we should also investigate if there is any benefit to integrate Version One with Replicon, so that Team Member’s do not have to enter the time worked on Tasks in two separate systems.
  • Achieving proficiency in managing WIP will exhibit enormous value for Application Support Teams because a combination of Scrum and Kanban is commonly used in these environments where Story Points and quite often Task Hour Estimates are not required.
  • Without applying a size/complexity swag to each Story, we cannot effectively nor efficiently address the question of “What is the estimated number of Sprints required to deliver the Product Backlog Stories?”
  • After 2 to 3 Sprints, a Team will be able to establish its Average Velocity. At this point, the Estimated Release/Project Roadmap should be recalculated using the Team’s Actual Velocity. For example, at the start of a Project the Team estimates that it can complete 20 Story Points per Sprint (2 week Sprints). With a Product Backlog Size of 400 Story Points, the Team Estimates that the Project will be completed at 20 Sprints (i.e. 400/20). However, after 2 Sprints, the Team is averaging a Velocity of 15 Story Points, so the revised number of Sprints to complete the project would then be 26 Sprints (i.e. (400-20)/15)
  • If Resources are shared across multiple Projects and Operational Support Activities, Version One is able to aggregate this data and communicate where any resource is over-allocated. Scrum Masters will then need assistance from PCH Online Leadership in determining which initiatives take priority. If Team Member Capacities are captured for a 60-day period, The Organization will be able to proactively forecast any Resource Constraints, which allows for early in-sourcing/out-sourcing of resources before the bottlenecks impact the delivery of the Project.
  • The majority of Project Health Metric Calculations factor in the Project Start Date. Whomever provides Project Authorization in The Organization should supply the Project Start Date.
  • Without a consistent Sprint Length a more effort goes into forecasting Project Delivery Dates. Velocity is the amount of Story Points that a Team can deliver for a Set Sprint Length. If this Sprint Length changes, Velocity needs to be re-calculated (i.e. the Team needs to work for another 2 to 3 Sprints to establish their new Velocity every time there is a change in Sprint Length).
  • A Team’s proficiency in self-organizing is directly related to the Organization’s ability to assist the Team in removing impediments. Impediment Cycle Time, enables PCH Online Leadership to assess how well Team’s are being supported. For example, if a certain type of Issue consistently has a “high cycle time”, then it may be beneficial to establish a Task Force to investigate elimination the occurrence of the issue and/or reducing its Cycle Time on all projects.
  • Scrum Project Health Standards

    1. 1. 1<br />Capture To-Do Hours for Sprint Tasks that are in-progress<br />WHAT<br />HOW<br />On a daily basis, Team Members will Update the Remaining To-Do Hoursfor their In-Progress Sprint Tasks<br />On average it should take between 2 and 5 minutes to log Remaining To-Do Hours for each In-Progress Tasks (note: most Team Members have no more than 2 to 3 In-Progress Tasks)<br />EFFORT<br />USAGE<br /><ul><li>Produce Sprint Burn Down Charts
    2. 2. Assess Sprint Demand vs. Available Team Capacity
    3. 3. Continuously Measure Task Estimation Accuracy
    4. 4. Calculate Sprint Cycle Time for Stories & Defects
    5. 5. Scrum Masters disrupting the pace and purpose of the Daily Scrum by seeking to receive To-Do Hours during the meeting
    6. 6. Team Members not accustomed to updating Sprint Tasks and To-Do Hours</li></li></ul><li>2<br />Capture Effort for Sprint Tasks that are in-progress<br />WHAT<br />HOW<br />On a daily basis, Team Members will Enter Hours Workedfor their In-Progress Sprint Tasks<br />On average it should take between 1 and 3 minutes to log Hours Worked for each In-Progress Tasks (note: most Team Members have no more than 2 to 3 In-Progress Tasks)<br />EFFORT<br />USAGE<br /><ul><li>Produce Sprint Burn Up Charts
    7. 7. Forecast Team Capacity Adjustments
    8. 8. Continuously Measure Task Estimation Accuracy
    9. 9. Calculate the Actual Effort and Cost to Produce a Story/Resolve a Defect
    10. 10. Scrum Masters disrupting the pace and purpose of the Daily Scrum by seeking to receive Effort updates during the meeting
    11. 11. Team Members not accustomed to updating Sprint Tasks and Effort
    12. 12. Perception of having to enter time twice (i.e. Replicon and Version One)</li></li></ul><li>3<br />Monitor and Continuously Update Sprint Work In Progress (WIP)<br />WHAT<br />HOW<br />On a daily basis, The Team will Update The Work State of Sprint Tasks, Tests, and Stories<br />This activity shall take place during the Daily Scrum, so it should average a maximum duration of 15 to 30 minutes (i.e. the duration of the Daily Scrum dictates the Effort)<br />EFFORT<br />USAGE<br /><ul><li>Provide Visibility into the True State of the Sprint Work via Story Boards, Task Boards, and Test Boards
    13. 13. Identify if The Team has Too Much Work In Progress Based on Team Size
    14. 14. Identify Opportunities for the Team to Accept Additional Sprint Work
    15. 15. Deciding whether to employ on-line and/or offline Information Radars
    16. 16. Ensuring that Offshore Team Members update their WIP
    17. 17. Product Owners and Team Members not familiar with using WIP Limits
    18. 18. No resolution offered to Teams for task/story over-allocations</li></li></ul><li>4<br />Define Story Points for all Stories in the Product Backlog<br />WHAT<br />HOW<br />At the beginning of the Project, and as additional Stories are added to the Product Backlog (Backlog), The Team supplies Size/Complexity Estimates for Stories (i.e. Story Points)<br />This activity shall take place during Release Planning (i.e. Part 1 of Sprint Planning). At a minimum, Release Planning should take place at Project Start; thereafter, it occurs prior to the start of each Sprint. These meetings can range from 2 hours to 2 days, depending on the size of the Product Backlog.<br />EFFORT<br />USAGE<br /><ul><li>Calculating Project Duration Estimates
    19. 19. Produce Project & Release Roadmaps
    20. 20. Produce the Release Burn Down Chart
    21. 21. Identifying if the Sprint Commitment Exceeds The Team’s Velocity
    22. 22. Teams and Product Owners not understanding the intent of Story Points
    23. 23. Teams and Product Owners attempting to associate Effort with Story Points</li></li></ul><li>5<br />Establish Velocity prior to Sprint Planning<br />WHAT<br />HOW<br />At the beginning of the Project, the Team takes an educated guess at its Velocity. Afterwards, the Average VelocityofRecently Completed Sprints is used to calculate the Velocity of the Current Sprint.<br />For new and existing projects, the discussion on Velocity typically ranges from 5 minutes to 30 minutes. On the lower end of the Effort scale, Teams exhibit a solid understanding of their Velocity, on the higher end Teams usually have experienced a change to their membership or Product Backlog Items.<br />EFFORT<br />USAGE<br /><ul><li>Calculating Project Duration Estimates
    24. 24. Produce Project & Release Roadmaps
    25. 25. Executing Release & Sprint Planning
    26. 26. Tracking Velocity Trends for Planning Purposes
    27. 27. Teams and Product Owners not understanding the intent of Velocity
    28. 28. Teams and Product Owners attempting to associate Velocity with Ideal Hours
    29. 29. Management comparing Team’s Productivity via Velocity</li></li></ul><li>6<br />Capture Individual Team Member Capacities prior to Sprint Planning and update throughout Sprint Execution<br />WHAT<br />HOW<br />During Sprint Planning (preferably near the beginning of the Sprint Planning Meeting), each Team Member shares his/her Sprint Capacity (i.e. # of Hours Available for the Sprint) and applies any adjustments to their respective Capacities throughout the Sprint<br />It may take a Team Member anywhere from 1 minute to 10 minutes to determine their Capacity for the Sprint, depending on the number of concurrent Projects and Operational Support activities they are allocated to<br />EFFORT<br />USAGE<br /><ul><li>Calculating Resource Utilization Metrics
    30. 30. Identify if Team Members are Over-Allocated
    31. 31. Administer Resource Allocation
    32. 32. Assess The Team’s Potential to Accept More Work into the Sprint
    33. 33. Scrum Masters not accustomed to monitoring Capacity vs. Demand throughout the Sprint
    34. 34. Team Members habitually accepting more work than they can complete during a single Sprint </li></li></ul><li>7<br />Define a Project Start Date for every initiative<br />WHAT<br />HOW<br />At the beginning of the Project, the Scrum Master and Product Owner are provided with the Project Start Date that the Organization will use for planning and reporting purposes<br />Determining a Project Start Date might take only a few minutes or a full-hour, depending on the adjustments to shared resources and other projects that that PCH Online Leadership must take into account<br />EFFORT<br />USAGE<br /><ul><li>Calculating Project Duration Estimates
    35. 35. Produce Project & Release Roadmaps
    36. 36. Building Integrated Project Dashboards
    37. 37. Identifying who owns the responsibility of defining and communicating Project Start Dates
    38. 38. Technology projects being kicked-off without the knowledge of IT</li></li></ul><li>8<br />Utilize a consistent Sprint Length for the Project<br />WHAT<br />HOW<br />At the beginning of the Project, the Scrum Master will negotiate a Set Sprint Length between the Product Owner and the Team<br />Establishment of a Set Sprint Length is a common output of the Team Working Agreement, and this activity generally takes place at the beginning of the Project and it is repeated at the start of subsequent Sprint Planning Meetings<br />EFFORT<br />USAGE<br /><ul><li>Calculate Project Duration Estimates
    39. 39. Produce Project & Release Roadmaps
    40. 40. Calculate Earned Value
    41. 41. Teams and Product Owners accustomed to modifying the Sprint Length throughout the delivery of the Project
    42. 42. Product Owners not comprehending how the combination of Sprint Length and Velocity are used to generate Project Duration and Scope Forecasts</li></li></ul><li>9<br />Monitor Impediment Cycle Time for Issues impacting the progress of The Team and/or Project Schedule<br />WHAT<br />HOW<br />The Scrum Master captures Issues as they are identified by the Team and Product Owner, Cycle Time is calculated by summing the number of hours/days from Issue Identification to Issue Resolution<br />Calculating Cycle Time is done automatically, so the Effort required to log Issues is minimal (i.e. if the Scrum Master is provided with sufficient details on the specifics of the Issue and any impacted work)<br />EFFORT<br />USAGE<br /><ul><li>Report Story and Task Blockages
    43. 43. Forecast Sprint and Project Schedule Delays
    44. 44. Perform Impediment Trend Analysis
    45. 45. Issues not resolved in a timely manner by parties external to The Team
    46. 46. Cycle Time is not appropriately used for continuous improvement of the Team’s ability to deliver working software</li>