Know your numbers

One of my favorite TV shows is Shark Tank. If you’ve never seen the show, the premise is simple: an entrepreneur brings their million-dollar idea to five investors who then decide if the idea is worth their investment. Shark Tank is a fun and educational reality show because viewers can see ambitions rewarded or crushed, usually because of something simple but complicated that the entrepreneur does right or wrong.

A popular trope on Shark Tank comes from a simple question: “what are your numbers?” Companies live and die by their metrics. KPIs (Key Performance Indicators) such as their profit and loss, cashflow and burn rate are crucial for any business, and especially for people pitching on Shark Tank. Sharks are much more likely to invest in people who thoroughly understand their company’s metrics. Then there are people like these folks:

The “shark tank attitude” apples to any Agile leaders: Agile leaders must always know their most important KPIs through and through. For more obscure metrics, any Agilist should know how to retrieve their essential data quickly.

Share the cold, hard facts

These numbers are objective performance metrics derived from the team’s single source of truth, their product tracking tool (Jira, TFS or Rally). They are clear, hard facts which can help drive decision-making because they are based on that single source of objective truth.

Here are a few metrics I like to always know for my Scrum teams:

• What is the burndown rate of tasks and stories by my team?
• What is the max and minimum number of stories my team has delivered recently?
• What is the team’s carryover from Sprint to Sprint?
• How many features are left incomplete at the end of the Program Increment?
• How many high-priority bugs do does a team take in during an average Sprint?
• What is the team’s happiness level, based on surveys?
• What is the team’s agile maturity level, based on surveys and observations?
• What is the team’s burnup rate towards the next major release?

There are lots more metrics you can track – I have a passion for using Value Stream Mapping as a way of reducing cycle times – but each team will have different needs. Experiment with the metrics that resonate most with your teams.

I like to embed these metrics in my teams’ dashboards, and I refer to this data often. I share the data in Daily Scrum, in Retrospectives and in Sprint Reviews, so everyone understands the team’s metrics.

Some more metrics to think about

I also like to track some other metrics for my own reference for reporting to management. A few examples:

• Breakdown between dev/analyst/QA
• Number of items blocked at any point during the Sprint
• Drag (the number of stories the team commits to, but which get removed during a Sprint)

More ways to uses metrics as conversation starters

Metrics are highly powerful as tools to help facilitate conversations. A few examples:

• When we’re loading a new Sprint, I can use metrics help the team load its capacity just right.
• When I’m talking to a VP, I can explain the need to stick to a plan in each Sprint.
• When I’m talking to team members, I can show them objectively what they have accomplished, and to spur them to try new things.
• Metrics are also essential KPIs to help determine next steps when an Agile Experiment wraps up.

Be the person who gets the investment from your company’s sharks. Know your numbers and have them ready to share. Expertise is always a good investment.

*Burndown chart by I8abug - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=15511814