In June 2015, I had an opportunity to share insights on advanced metrics for agile and Scrum teams at Big Apple Scrum Day in New York City.  The metrics I highlighted were all aimed at allowing teams to better assess the impact of changes and improvements they put in place while creating and delivering software.  My motivation behind sharing additional metrics for teams was based upon positive experiences where I have observed that having data from metrics improves team self management as teams can make decisions based on upon fact rather than opinion.

The presentation included a disclaimer, whereby teams need not track all 30+ metrics highlighted in the presentation, but rather teams should track sufficient metrics to have a full understanding of their process.  Since there is a cost to gather and review data for each metric, tracking 30+ metrics on a team may be a bit too much – my intent in the presentation was to show options and ideas on what you can measure on a team / software development project that those attending may not have thought about before.  Since all teams are different (since they are composed of different people and have different areas in which they are working to improve), it can be expected that different teams will track different metrics and this is OK.  Moreover, a team may start tracking a new metric to assess a specific challenge or improvement; however, once the team improves in that area, they may find it no longer necessary to track that metric – the metrics a team tracks should change over time.

In the presentation I highlighted 5 different categories of agile / Scrum metrics and recommended that teams track a few metrics across each of the following 5 categories to be able to assess software development, delivery and continuous improvement activities:

• Process Health Metrics – Assess day-to-day delivery team activities & evaluate process changes
• Release Metrics – Direct focus to identify impediments to continuous delivery
• Product Development Metrics – Align product features to user needs
• Technical / Code Metrics – Determine quality of implementation and architecture
• People / Team Metrics – Promote sustainable pace and team engagement

While highlighting various metrics across these 5 categories, several questions did come up which generated insights not included in the presentation and reference materials below:

Someone asked – “How can you figure out Business Value Points for the items in your backlog?” – Two activities / games I recommended and have used:

• Buy-A-Feature – http://www.innovationgames.com/buy-a-feature/
• The Business Value Game (also called business value poker buy some) – http://media.agile42.com/content/Business_Value_Game.pdf

Both of these games allow for business value to be assigned to the items in your backlog in a collaborative manner.

Someone asked – “How do you get test coverage data?” – The best way to do this is to setup your continuous integration (build) server (Jenkins or equivalent) with the appropriate plug-ins for the language that you are coding in – as an example go the Jenkins wiki on “Build Reports” (https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Buildreports) and search for “coverage” and you’ll see a variety of plug-ins you can integrate with Jenkins to capture test coverage for every build.

Someone asked – “How do you collect Happiness metric data?” – Two techniques I recommended and have used:

• For co-located teams, put a shoe box in the team area along with a supply of Red, Yellow and Green note cards – at the end of each day, team members put a card into the box to capture their happiness for the day (Green = Happy; Red = Not Happy; Yellow = Everything else), then open the box, review its contents, and discuss ideas/insights at your team retrospective.  With this technique, some teams find it interesting to write the date on each colored note card as it is submitted into the box – this will allow you to correlate happiness with specific days during a sprint.
• For distributed teams, you can achieve the same outcome by creating an online survey (SurveyMonkey) or Google Form and allow people to enter their happiness for the day – then create a graph of the data for discussion during your retrospective.

Something to add – Additional insights on cycle time – When we talked about cycle time we focused mainly on capturing the time required to complete development and testing of a story; however, many groups I have worked with found value in measuring the cycle time required to create and refine stories so they are ready for development.  I have worked with several teams that track stories as they are being created on a separate board so they can collect the cycle time of story writing & refinement.  Reviewing the cycle time of the activities to write / review stories has allowed those groups to identify impediments that were slowing down story writing activities.

Thanks to the organizers of Big Apple Scrum Day for the opportunity to insights on advanced metrics with conference attendees.

Presentation Materials

Check out the links below to download the presentation and metrics reference sheet from Big Apple Scrum Day (June 2015):

Presentation Slides:

Presentation Handout – Metrics Reference Sheet: