Capture To-Do Hours for Sprint Tasks that are in-progress

On a daily basis, Team Members will Update the Remaining To-Do Hours for their In-Progress Sprint Tasks

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)

• Produce Sprint Burn Down Charts• Assess Sprint Demand vs. Available Team Capacity• Continuously Measure Task Estimation Accuracy• Calculate Sprint Cycle Time for Stories & Defects

• Scrum Masters disrupting the pace and purpose of the Daily Scrum by seeking to receive To-Do Hours during the meeting

• Team Members not accustomed to updating Sprint Tasks and To-Do Hours

WHAT

HOW

EFFORT

USAGE

1

Capture Effort for Sprint Tasks that are in-progress

On a daily basis, Team Members will Enter Hours Worked for their In-Progress Sprint Tasks

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)

• Produce Sprint Burn Up Charts• Forecast Team Capacity Adjustments• Continuously Measure Task Estimation Accuracy• Calculate the Actual Effort and Cost to Produce a Story/Resolve a Defect

• Scrum Masters disrupting the pace and purpose of the Daily Scrum by seeking to receive Effort updates during the meeting

• Team Members not accustomed to updating Sprint Tasks and Effort• Perception of having to enter time twice (i.e. Replicon and Version One)

WHAT

HOW

EFFORT

USAGE

2

Monitor and Continuously Update Sprint Work In Progress (WIP)

On a daily basis, The Team will Update The Work State of Sprint Tasks, Tests, and Stories

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)

• Provide Visibility into the True State of the Sprint Work via Story Boards, Task Boards, and Test Boards

• Identify if The Team has Too Much Work In Progress Based on Team Size• Identify Opportunities for the Team to Accept Additional Sprint Work

• Deciding whether to employ on-line and/or offline Information Radars• Ensuring that Offshore Team Members update their WIP• Product Owners and Team Members not familiar with using WIP Limits• No resolution offered to Teams for task/story over-allocations

WHAT

HOW

EFFORT

USAGE

3

Define Story Points for all Stories in the Product Backlog

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)

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.

• Calculating Project Duration Estimates• Produce Project & Release Roadmaps• Produce the Release Burn Down Chart• Identifying if the Sprint Commitment Exceeds The Team’s Velocity

• Teams and Product Owners not understanding the intent of Story Points• Teams and Product Owners attempting to associate Effort with Story Points

WHAT

HOW

EFFORT

USAGE

4

Establish Velocity prior to Sprint Planning

At the beginning of the Project, the Team takes an educated guess at its Velocity. Afterwards, the Average Velocity of Recently Completed Sprints is used to calculate the Velocity of the Current Sprint.

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.

• Calculating Project Duration Estimates• Produce Project & Release Roadmaps• Executing Release & Sprint Planning• Tracking Velocity Trends for Planning Purposes

• Teams and Product Owners not understanding the intent of Velocity• Teams and Product Owners attempting to associate Velocity with Ideal

Hours• Management comparing Team’s Productivity via Velocity

WHAT

HOW

EFFORT

USAGE

5

Capture Individual Team Member Capacities prior to Sprint Planning and update throughout Sprint Execution

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

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

• Calculating Resource Utilization Metrics• Identify if Team Members are Over-Allocated• Administer Resource Allocation• Assess The Team’s Potential to Accept More Work into the Sprint

• Scrum Masters not accustomed to monitoring Capacity vs. Demand throughout the Sprint

• Team Members habitually accepting more work than they can complete during a single Sprint

WHAT

HOW

EFFORT

USAGE

6

Define a Project Start Date for every initiative

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

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

• Calculating Project Duration Estimates• Produce Project & Release Roadmaps• Building Integrated Project Dashboards

• Identifying who owns the responsibility of defining and communicating Project Start Dates

• Technology projects being kicked-off without the knowledge of IT

WHAT

HOW

EFFORT

USAGE

7

Utilize a consistent Sprint Length for the Project

At the beginning of the Project, the Scrum Master will negotiate a Set Sprint Length between the Product Owner and the Team

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

• Calculate Project Duration Estimates• Produce Project & Release Roadmaps• Calculate Earned Value

• Teams and Product Owners accustomed to modifying the Sprint Length throughout the delivery of the Project

• Product Owners not comprehending how the combination of Sprint Length and Velocity are used to generate Project Duration and Scope Forecasts

WHAT

HOW

EFFORT

USAGE

8

Monitor Impediment Cycle Time for Issues impacting the progress of The Team and/or Project Schedule

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

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)

• Report Story and Task Blockages• Forecast Sprint and Project Schedule Delays• Perform Impediment Trend Analysis

• Issues not resolved in a timely manner by parties external to The Team • Cycle Time is not appropriately used for continuous improvement of the

Team’s ability to deliver working software

WHAT

HOW

EFFORT

USAGE

9