Let's look at an info-graphic of a beginning team's metrics and use this as a case study in Scrum Team Metrics.
Description of charts:
Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done. This includes the task yet to be started, and task in process.
Tasks in Process - a daily count of the number of tasks in process.
Tasks Done - a daily count of the number of tasks that are done.
Stories Done - a daily count of the number of Stories that are done.
Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review.
The Back Story on this team:
This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process. The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing. After some weeks of observations and workshops with the team - they decided to "hit the reset button" on doing Scrum. Sprint One in the info-graphic is the first sprint right after a week long workshop on learning Scrum practices and principles. Key to this team's adoption of Scrum is their adoption of a physical task board (see also Elements of an Effective Scrum Task Board).
Observations on Sprints:
Sprint One - Started with many stories from past sprint that were not yet done - as the team had no empirical data of velocity we guessed at how many stories we could complete in the 2 week sprint, and chose 15 stories. At this point we had 4 product silos where people we working within the silo to deliver the stories - very little cross team collaboration.
Sprint Two - Tear down the silo walls - the team decided that the original silos of working was harming a long term desire of cross-functional team members - so a removal of the silo walls (tape on the scrum task board) happened.
Sprint Three - Enforced the use of empirical data to constrain the team's selection of how many stories to bring into the sprint (team select top 5 stores and finished all of them).
Sprint Four - Team planed for 30 points of stories but finished early and pulled in additional stories and finished them within the sprint.
Objectives for the Team:
This teams objectives for hitting the reboot button on a scrum implementation was to achieve a consistent level of reliability to deliver value (stories) to the business. Also to maintain and supporting the existing 4 products line internal organizational clients, and transitioning tacit knowledge from several remote employees to the team and increasing cross-functional capabilities of the team members.
Commentary on Metric Charts:
Burndown - Sprint 1 and 2 task burndown charts show that the team started with around 100 aspirin and discovered between 50 and 100 aspirin more by doing the work - but didn't finish the 15 stories and left lots of stories started but incomplete at the end of the sprint. In sprint 3 and 4 the team had developed the ability to forecast the proper amount of work to pull into sprint planning and were able to deliver the completed stories.
Tasks in Process - this simple metric showed that the team of about 8 people were consistently task switching. There are many "reasons" (excuses) for this behavior, and it is a hard habit to correct in this era of high utilization rate driven management. Just tracking this metric had little effect on the teams behavior - however we had empirical data that other practices (avatars, re-estimating in process tasks, etc.) had a positive effect upon this metric over several sprints.
Tasks Done - this metric is redundant for a team using a traditional sticky note task board. In general this reflects the sprint burndown. It does point out for this team that tasks done stalls out when there support tasks flare up, as these support (maintenance and production, M&P) issues require task switching to the more urgent unplanned work. Reflecting upon this metric lead the team to start tracking the planned tasks separate from the urgent support tasks in our burndown chart for sprint 5.
Stories Done - an interesting trend shows up in this simple to trend metric. The team was capable of finishing 5 stories, regardless of how many they planned. In sprint 3 when the team constrained the planning to the empirical evidence (~28 points, 5 stories) they had there first successful sprint (on time, on budget, with planned scope).
Capabilities developed by the Team not shown in these Metrics:
Tasking - working toward tiny tasks. Within the first two sprints the focus was to develop the ability to task stories. Several synergic practices lead to this capability - re-estimating each time the task is touched in stand-up; recognizing that task that last for several days are way-too-large; learning to decompose tasks that are too large; realizing that doing work leads to discovery of new tasks that need to be recorded and added to the board. See Also: What belongs on the TASKS board?
Single Piece Flow - working on a task until it is done. Smaller task effect this behavior in a virtuous manner. Re-estimating each day makes the antithesis of this pattern apparent, and also offers the opportunity for team members to recognize when help is needed. The use of avatars on the story tasks reinforces the practice of lowering work in process and reducing task switching.
In Sprint 5 the team decided to move from a 2 week time box to a 3 week sprint. The charts also show the support (M&P) tasks tracking independently of the planned tasks and the new chart at the bottom (M&P task vs Planned task deltas per day) indicates the inverse relationship of the priority shifts the team has to deal with.
Next Objectives:
Develop the capabilities to deliver agile release plans and forecast feature release time frames for business coordination with other teams that depend upon the infrastructure product lines developed by this team.
At the team coaching level an objective is to measure cycle time of stories within scrum teams.
See Also:
Metrics for a Scrum Team - 10 suggested metrics and examples
Measuring Process Improvements - Cycle Time by Mishkin Berteig, June 2008
Description of charts:
Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done. This includes the task yet to be started, and task in process.
Tasks in Process - a daily count of the number of tasks in process.
Tasks Done - a daily count of the number of tasks that are done.
Stories Done - a daily count of the number of Stories that are done.
Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review.
The Back Story on this team:
This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process. The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing. After some weeks of observations and workshops with the team - they decided to "hit the reset button" on doing Scrum. Sprint One in the info-graphic is the first sprint right after a week long workshop on learning Scrum practices and principles. Key to this team's adoption of Scrum is their adoption of a physical task board (see also Elements of an Effective Scrum Task Board).
Observations on Sprints:
Sprint One - Started with many stories from past sprint that were not yet done - as the team had no empirical data of velocity we guessed at how many stories we could complete in the 2 week sprint, and chose 15 stories. At this point we had 4 product silos where people we working within the silo to deliver the stories - very little cross team collaboration.
 |
| Rules silo |
Sprint Three - Enforced the use of empirical data to constrain the team's selection of how many stories to bring into the sprint (team select top 5 stores and finished all of them).
Sprint Four - Team planed for 30 points of stories but finished early and pulled in additional stories and finished them within the sprint.
Objectives for the Team:
This teams objectives for hitting the reboot button on a scrum implementation was to achieve a consistent level of reliability to deliver value (stories) to the business. Also to maintain and supporting the existing 4 products line internal organizational clients, and transitioning tacit knowledge from several remote employees to the team and increasing cross-functional capabilities of the team members.
Commentary on Metric Charts:
Burndown - Sprint 1 and 2 task burndown charts show that the team started with around 100 aspirin and discovered between 50 and 100 aspirin more by doing the work - but didn't finish the 15 stories and left lots of stories started but incomplete at the end of the sprint. In sprint 3 and 4 the team had developed the ability to forecast the proper amount of work to pull into sprint planning and were able to deliver the completed stories.
Tasks in Process - this simple metric showed that the team of about 8 people were consistently task switching. There are many "reasons" (excuses) for this behavior, and it is a hard habit to correct in this era of high utilization rate driven management. Just tracking this metric had little effect on the teams behavior - however we had empirical data that other practices (avatars, re-estimating in process tasks, etc.) had a positive effect upon this metric over several sprints.
Tasks Done - this metric is redundant for a team using a traditional sticky note task board. In general this reflects the sprint burndown. It does point out for this team that tasks done stalls out when there support tasks flare up, as these support (maintenance and production, M&P) issues require task switching to the more urgent unplanned work. Reflecting upon this metric lead the team to start tracking the planned tasks separate from the urgent support tasks in our burndown chart for sprint 5.
Stories Done - an interesting trend shows up in this simple to trend metric. The team was capable of finishing 5 stories, regardless of how many they planned. In sprint 3 when the team constrained the planning to the empirical evidence (~28 points, 5 stories) they had there first successful sprint (on time, on budget, with planned scope).
Capabilities developed by the Team not shown in these Metrics:
Tasking - working toward tiny tasks. Within the first two sprints the focus was to develop the ability to task stories. Several synergic practices lead to this capability - re-estimating each time the task is touched in stand-up; recognizing that task that last for several days are way-too-large; learning to decompose tasks that are too large; realizing that doing work leads to discovery of new tasks that need to be recorded and added to the board. See Also: What belongs on the TASKS board?Single Piece Flow - working on a task until it is done. Smaller task effect this behavior in a virtuous manner. Re-estimating each day makes the antithesis of this pattern apparent, and also offers the opportunity for team members to recognize when help is needed. The use of avatars on the story tasks reinforces the practice of lowering work in process and reducing task switching.
In Sprint 5 the team decided to move from a 2 week time box to a 3 week sprint. The charts also show the support (M&P) tasks tracking independently of the planned tasks and the new chart at the bottom (M&P task vs Planned task deltas per day) indicates the inverse relationship of the priority shifts the team has to deal with.
Next Objectives:
Develop the capabilities to deliver agile release plans and forecast feature release time frames for business coordination with other teams that depend upon the infrastructure product lines developed by this team.
At the team coaching level an objective is to measure cycle time of stories within scrum teams.
See Also:
Metrics for a Scrum Team - 10 suggested metrics and examples
Measuring Process Improvements - Cycle Time by Mishkin Berteig, June 2008
Comments