Metrics available on Plandek
Plandek’s powerful self-config capability enables users to create a myriad of Agile, delivery, engineering and DevOps metrics (including the DORA metrics). Here, we list just some of the key metrics for software delivery available in Plandek. Available in OTB dashboards or build your own!
- Strategic priorities
- Backlog & capacity
- Delivery efficiency
- DevOps capability
- Key knowledge risks
- Operation & technical debt
- Sprint effectiveness
Is our finite resource focused on our strategic priorities?
Value Stream
Keep track of how value, throughput and resource is allocated across your strategic roadmap initiatives, lines of business, portfolio or value streams.
Opex/Capex
Quickly analyse how your delivery is allocated across Capex and Opex.
Delivered Story Points (SP)
Look across your portfolio to analyse how velocity and work items are delivered by work stream, programme, team and so on.
Delivered Value Points (VP)
Maintain a close eye on the value delivered to users, whether you use value points or a nominal business value estimate.
Stories by epic
Is our backlog healthy and are we utilising capacity efficiently?
Story Points (SP) ready for Dev
Do you know how much runway your teams have? Ensure utilisation is high and teams aren’t stuck staring at one another.
Design time
Optimise the time it takes to design and groom new work so the team has plenty to do and lead time is as short as possible.
Backlog distribution
If a team is running low on work, it’s critical to understand where new work currently sits upstream in order to fully assess the risk of running out of work.
How efficiently are we working to deliver key work?
Flow efficiency
Quickly identify and alleviate “waste” in your delivery. Spot capacity issues, poor collaboration and/or process inefficiencies that are holding your teams back.
Epic flow
Track the delivery of the underlying work items (e.g. stories) to ensure your Epics are flowing efficiently through to delivery.
Fix version flow
Get a bird’s eye view of your releases across teams. Ensure that any bottlenecks are quickly spotted and resolved.
First Time Pass Rate (FTPR)
The ability for stories and tasks to pass “first time” is down to strong collaboration and communication within teams. One of the strongest measures of a health team.
Code cycle time
Make dramatic improvements to Cycle Time by dissecting your Pull Request (PR) review process. Analyse how long it takes to review, approve, merge and deploy code.
Speeding
A team’s board plays a central role in their decision making, so it’s critical to understand how well boards reflect reality through tracking unwanted ticket shepherding habits.
Lead time
Time to market is driven by the ability to transform an idea into functioning software for users, and Lead Time enables you to dissect every stage of this process to ensure you’re operating at your full potential.
Cycle time
The focal point for most development teams, Cycle Time enables you to examine your engineering and DevOps capability to ensure you can build and ship code as quickly as possible.
How well are we delivering and how is our DevOps capability evolving?
Deployments
Track the number and/or frequency of deployments as a key indicator for your maturing DevOps capability. Understand which pipelines are performing well and which pipelines need some support.
Build fail rate
Understand how frequently your builds are failing and particularly which pipelines are most plagued by failures in order to focus the team’s attention in the right areas.
Flaky PRs
Cross-reference your git and build data to quickly identify which of your files are often the cause of build failures.
Mean build time
Quickly spot which build processes are lagging and may require optimisation to ensure your teams can keep building and testing software.
Failed build time
When builds fail, they need to fail fast so the impact is kept to a minimum. Restructure your build processes to frontload complexity.
Time to recover from failed build
How quickly can the team recover from a failed build? Understanding and minimising this downtime is critical to building a strong DevOps capability and service within your organisation.
Build costs (CCI)
CircleCI customers need to understand where their spend is allocated, particularly how much is being spent on failed builds so they can optimise their spend. A great way to ensure you’re getting as much value as possible from CircleCI.
How are our engineering practices and are there key knowledge risks?
Ticket complexity
Through connecting your commits and tickets, discover which of your stories, bugs, etc are the most complex based on a number of factors including repos touched, developers involved and lines of code changed.
Commits without Pull Requests (PRs)
Mitigate risk in your code base by ensuring all merges to master/trunk have been reviewed and approved through the PR process.
Commit frequency
Drive up best practice around smaller, more frequent commits. A great metric to gamify within your teams.
PRs w/o ticket ref
Whether a regulatory requirement or just best practice, ensure that all pull requests reference back to the ticket outlining the scope and authorisation of changes.
Created Pull Requests (PRs)
Analyse PR activity across your code base, and gain further insights around understanding which of your stories, bugs and so on are currently most active.
Code knowledge
Build a better understanding of relationships in your team, who works most frequently together and whether you have any potential risks of knowledge being consolidated in a small number of senior devs.
Ticket commit hotspots
Filter commit activity in your code base so you can isolate the files and repos most touched when delivering new stories or resolving bugs.
How well are we responding to operational issues and technical debt?
P1/P2 resolution
Understand how quickly bugs are being resolved, and where in the process there are opportunities to improve your resolution times.
Bug backlog
Maintain a close eye on your current bug backlog, and break down the data by release, environment or a number of other fields that will improve your understanding of your bug backlog.
Escaped defects
Isolate the number of defects that have escaped your testing process and landed with users in production. Optimise your test scripts where reasonable to improve test coverage and product quality.
Are we planning and running our sprints effectively?
Sprint target
A team’s ability to plan and deliver the sprint objectives is critical to meeting mid- and long-term commitments. See how well your teams deliver against their targets for each sprint.
Sprint flow
Whether preparing for a stand-up or reviewing in a retro, get a day-by-day breakdown of how your work flows from “to do” to “done”. Identify and remedy any bottlenecks as they happen and improve your sprint performance.
Sprint scope
Scope change is one of the major headaches for Scrum teams. With this metric, you can track exactly which tickets are being added and removed every day to ensure the team stays on track.
Sprint goals
Stories, bugs, and tasks are great, but ultimately it’s about distilling a sprint down to 2-3 overall goals and measuring how effective teams are at delivering them.
