Agile metrics that PMO’s can understand

  1. Home
  2. Blog
  3. Agile metrics that PMO’s can understand

Agile metrics that PMO’s can understand

A wooden ruler with the words To Measure is to Know, symbolizing the importance of gathering information when attempting to learn the nature of an object or issue

A wooden ruler with the words To Measure is to Know, symbolizing the importance of gathering information when attempting to learn the nature of an object or issue

Using typical reporting metrics such as burn-down, burn up, velocity and backlog size may not be enough to keep all program level stakeholders on the same page as the Scrum teams.  Some of the big mis-understandings that typically happen are mis-interpreted project estimates and progress.  This can give rise to mis-understanding of project status and in turn cause mis-allocation and mis-management of resources.  A snowball effect of problems will soon follow that impact the project team and the organization.

To bridge this gap in understanding, two strategies can be used:

1) Feature and user story based estimates instead of task based estimates

Project management schedules need to incorporate and/or replace a percent complete on gantt charts with features or user stories instead of tasks.  Tracking percent complete for tasks is very mis-leading.  This is because a task list can grow and change dynamically based on the variability inherent in the development process.  Plus tasks are not what’s being delivered to the customer, its features that are being delivered.  So, percent complete on features and user stories are of primary concern.  When necessary, a breakdown of what tasks are necessary to complete the features and user stories can be retrieved if this kind of detailed insight is required.  But, this type of information should not be the primary basis of estimating and tracking for project schedules.

2) Normalizing story point estimates across Scrum teams.

When teams estimate stories, all teams should use a 1 days effort equals a 1 point story as the basis to estimate with.  Teams should then estimate all the remaining stories relative to the agreed upon sample 1 point story.  Point values should be assigned based on the fibinocci sequence.  A delphi, or planning poker process should be followed when assigning points. This estimating process produces estimates that scale across multiple teams.  When viewed at the program level, project managers can easily fit these estimates into project timelines, milestones and release dates.

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu