Get started

Metric Definition

Speeding Transitions Rate is a useful Agile delivery metric. It looks at how effectively workflow management tools (e.g. Jira, Azure DevOps) are being used by the engineering teams.  Specifically, it tracks how accurately teams are updating ticket statuses as work moves through the software delivery process.

‘Speeding tickets’ are defined as those that spent less than 60 seconds in a particular ticket status.  As such, it shows where engineers are retrospectively updating ticket statuses (e.g. at the end of a sprint), having forgotten to do so in real time.

If this is happening, it is very difficult to analyse workflow and make delivery process improvements – as there is no record of actually when tickets where in a certain status and for how long they really remained in that status.

As such when the Speeding Transitions Rate is high it becomes impossible to analyse Cycle Time and Flow Efficiency and identify where bottlenecks may lie within the end-to-end delivery process.

Speeding Transitions Rate is a popular metric in Plandek for teams keen to improve their basic processes and usage of their DevOps toolset.  As per below, Plandek allows Team Leads to define different durations, for their own definition of ‘speeding’ (e.g. they may choose to track a time length longer than 60 seconds).

 

Example Speeding Transitions Rate Formula

Example Speeding Transitions Rate chart – Plandek Delivery Efficiency dashboard

Example Speeding Transitions Rate drill-down chart

 

Analysis of Speeding Transitions Rate – Breakdown and Filtering Options

Delivery metric dashboards like Plandek enable you to analyse delivery, engineering and DevOps metrics in a number of different ways.

For example, you can analyse the Speeding Transitions Rate, by team, by issue type (as per the graphic below), by transition and over time.

Example Speeding Transitions Rate drill-down chart – Plandek Delivery Efficiency dashboard

Example Speeding Transitions Rate chart

 

This enables teams to quickly identify where the problem lies and to coach the engineers responsible in the importance of using workflow management tools effectively – in order to provide real visibility of the workflow process.

Related metrics

Speeding Transitions Rate is a useful ‘process hygiene’ metric to improve DevOps tool usage in Agile teams.

In essence, it is a stepping-stone to achieving data-driven delivery through the analysis of critical delivery metrics such as Cycle Time, Lead Time and Flow Efficiency.

Key use cases

Organisations often think that they are unable to move to a metrics-led delivery culture, because their underlying usage of tools like Jira is limited/compromised.

Indeed, we often hear delivery managers who say… ‘we are not yet ready for an analytics tool like Plandek as our underlying processes and usage of Jira need tightening up first…’

However, Plandek’s ability to surface metrics like Speeding Transitions Rate – shows why this argument is flawed.  Indeed, Plandek is a useful analytics tool especially if there is concern about imperfect usage of Jira or related DevOps tools!

Because until teams start tracking metrics like Speeding Transitions Rate and tightening up on the usage of their workflow management tools – they will never be able to move to a data-driven, continuous improvement Agile culture.

Speeding Transitions Rate should therefore be analysed as a first step towards moving to a data-led delivery culture, where teams have total visibility of their own end-to-end delivery process so that they self-improve over time.

Expected outcomes

A high level of Speeding Transitions Rate is to be avoided.  It is symptomatic of poor systems usage and results in limited visibility of teams’ workflows.  It therefore prevents, effective analysis of Cycle Time and Flow Efficiency and as such may well conceal bottlenecks in the end-to-end delivery process.

On the other hand, reducing Speeding Transitions Rate results in immediate benefit, as it makes the effective analysis of teams’ workflows possible and is therefore a key stepping-stone to data-driven Agile delivery.

About Plandek

Plandek works by mining data from toolsets used by delivery teams (such as Jira, Git, CI/CD tools and Slack), to provide end-to-end delivery metrics/analytics to optimise software delivery predictability, risk management and process improvement.

Plandek is a global leader in this fast-growing field, recognised by Gartner as a top nine global vendor in their DevOps Value Stream Management Market Guide (published in Sept 2020).

Plandek is based in London and works with clients globally to apply predictive data analytics and machine learning to deliver software more effectively.

Plandek metric of the week: Deployment Frequency

Metric Definition

Deployment Frequency is a core DevOps metric and more broadly a core Agile delivery metric.  As the name suggest it tracks the frequency with which increments of code are deployed to staging, testing and production.

As the core objective of Agile software delivery is ‘..the early and continuous delivery of valuable software..’, Deployment Frequency is a core Agile metric and represents a core objective of effective DevOps.  Deployment Frequency is also one of the four DORA metrics popularised by the DevOps Research and Assessments (DORA) group.

The software delivery process should be seen as an end-to-end value delivery process – as such Deployment Frequency is best viewed alongside a broader range of agile delivery metrics measuring: value delivery; delivery efficiency; dependability; backlog health; delivery and engineering quality; and DevOps processes.

Example Deployment Frequency chart – Plandek DevOps dashboard

Example Deployment Frequency chart – Plandek DevOps dashboard

The calculation of Deployment Frequency requires surfacing data from CI/CD tools (e.g. Jenkins, CircleCI).  This is typically done via reporting plug-ins to such tools or via an end-to-end delivery metrics dashboard like Plandek (www.plandek.com).

Analysis of Deployment Frequency – Breakdown and Filtering Options

Delivery metric dashboards like Plandek enable you to analyse delivery, engineering and DevOps metrics in a number of different ways.

For example, you can analyse the frequency of deployments by branch, portfolio, programme, repository or team.  As such targets can be set and practical actions taken to increase deployment frequency.

Example Deployment Frequency drill-down chart – Plandek DevOps dashboard

Example Deployment Frequency drill-down chart – Plandek DevOps dashboard

Related metrics

Deployment Frequency is one of many DevOps metrics – and agile delivery metrics more broadly.  As such it is often used is part of a ‘balanced scorecard’ of agile delivery and DevOps metrics surfaced in real time.

The DORA metrics often closely associated with Deployment Frequency are:

Key use cases

Deployment Frequency is a key DevOps metric used to ensure that software is delivered early and often.  Much emphasis might be placed on tracking and improving development-oriented metrics such as Cycle Time, Throughput – but the acid test is that the software developed by the engineering team is regularly deployed to live (otherwise all that effort is wasted).  Hence Deployment Frequency is not only a critical DevOps metric, but also a critical broader Agile delivery metric.

It should therefore form a part of a wider group of Agile software delivery metrics tracked over time at team and programme level.

Deployment Frequency is particularly important for:

 Expected outcomes

A high level of Deployment Frequency is a core Agile software delivery objective – as it ensures the delivery of value ‘early and often’.

Inexperienced Agile teams may have a very low deployment Frequency (e.g. bi-annual, quarterly or monthly deployments). Mature Agile DevOps organisations have successfully increased that frequency to daily deployments.

Experience shows that high frequency deployments deliver value more rapidly over the longer term for three reasons:

About Plandek

Plandek works by mining data from toolsets used by delivery teams (such as Jira, Git, CI/CD tools and Slack), to provide end-to-end delivery metrics/analytics to optimise software delivery predictability, risk management and process improvement.

Plandek is a global leader in this fast-growing field, recognised by Gartner as a top nine global vendor in their DevOps Value Stream Management Market Guide (published in Sept 2020).

Plandek is based in London and works with clients globally to apply predictive data analytics and machine learning to deliver software more effectively.

Plandek Metric of the Week: Commits Without a Pull Request

Commits Without a Pull Request (CWPR) is an important engineering metric for all organisations and particularly those focused on software engineering quality and DevSecOps.

It measures all merges to master that have not been peer reviewed (i.e. do not have a related pull request). This is generally considered as poor engineering practice and a potential security concern, particularly in organisations with engineers of variable experience and varied familiarity with the code base.

CWPR rates may vary widely between teams, locations, contractors etc – and hence it is a key software engineering quality metric. As such, software delivery teams at a higher level of Agile DevOps maturity will routinely focus on CWPR is a part of their broader engineering quality management process.

It is also a popular metric for delivery teams focused on DevSecOps, as effective DevSecOps recognises that teams and engineers themselves need to consistently put engineering security at the heart of their daily routines and processes.

Example Commits without a Pull Request summary chart – Plandek Delivery and Engineering Quality Dashboard

Example Commits without a Pull Request breakdown chart – Plandek delivery and engineering quality dashboard

As shown in the expanded view of CWPR above, the measure allows Teams Leads and Engineering Managers to review CWPR rates by committer and repo over time. The advanced filter functionality within Plandek also enables more detailed breakdowns such as by ticket issue type, ticket labels, and ticket status.

The expanded view therefore enables teams to rapidly identify where the problems lie and to improve CWPR levels. For some organisations, 100% compliance (i.e. a CWPR level of 100%) would be the minimum target. In other organisations, CWPR targets may be set by project, team, location etc. Our experience shows that typically a CWPR rate of over 10% is seen as a serious concern.

Related metrics

Commits Without a Pull Request is often used in conjunction with other delivery and engineering quality metrics. Commits Without a Ticket Reference is another related engineering quality metric. It tracks the percentage of code commits made to any branch that do not have a related (e.g. Jira) ticket reference. The ticket reference is required for effective root-cause analytics – to trace the links between tickets and code commits.

Other delivery and engineering quality metrics include measures of software quality such as: Escaped Defects, Bug Resolution Time and Unresolved Bugs.

Key use cases

Commits Without a Pull Request is used to monitor a key discipline the underpins engineering process quality – namely the peer review of code before it is committed by an individual engineer.
As such, it is a key engineering quality metric that needs careful monitoring to ensure both code quality and code security, as part of good DevSecOps practice. More broadly it is a good indicator metric of general process adherence and security disciplines within a software delivery team.

Tracking Commits Without a Pull Request may be particularly useful for:

  1. Immature delivery teams new to adopting Agile DevOps methodologies and tools
  2. Distributed software delivery teams consisting of a wide variety of engineer types: in-house, contractor, onshore, offshore etc. As such environments may involve a higher turnover of engineers and many who are unfamiliar with the code base
  3. Complex, strategically critical software delivery projects involving the build of new applications and features
  4. Businesses with robust regulatory requirements and/or very high risk profiles.

Expected outcomes

By reducing Commits Without a Pull Request, delivery teams will significantly reduce a key potential source of quality and infosec risk. In certain circumstances, regulatory requirements will mandate that CWPRs are tracked and reported on, in order to demonstrate effective quality and infosec procedures.

Plandek Metric of the Week: Sprint Target Completion

Metric Definition

‘Scrum Teams’ and ‘Sprints’ are the basic building blocks of Scrum Agile software delivery.

If Scrum Teams consistently deliver their Sprint goals (a ‘Sprint’ typically involving a two-week increment of work) – Scrum Agile software delivery can become a very effective way of rapidly delivering quality software.

On the other hand, if Scrum teams fail to deliver their planned sprint goals, then it quickly becomes difficult to plan delivery outcomes across multiple teams and longer time periods. Scrum team predictability (often referred to as ‘dependability’) is therefore a critical success criteria in Agile software delivery.

As such Sprint Target Completion is a core Scrum Agile delivery metric as it is the basic measure of a Scrum Team’s ability to hit their (self-imposed) sprint goals – and hence their dependability. It not only reflects the team’s ability to execute against their goals, but also how well they plan their sprint. It is commonly viewed alongside the broader metric of Sprint Completion which is calculated as:

How to work out Sprint Completion

Sprint Target Completion is the more precise measure as it looks at the percentage of tickets completed within a sprint from the tickets that started the sprint (i.e. were targeted for completion at the beginning of the sprint).

High performing Scrum teams will consistently have Sprint Target Completion rates in excess of 85% to account for inevitable (and indeed encouraged) changes over the course of the sprint.

Example Sprint Target Completion summary chart – Plandek delivery dependability dashboard

Example Sprint Target Completion review chart – Plandek delivery dependability dashboard

As shown in the expanded view of Sprint Target Completion above, the measure allows Teams Leads to review sprint performance over time. And for each Sprint, the chart shows: of the tickets planned for delivery at the outset of the Sprint, those tickets successfully completed during the Sprint, those tickets left incomplete at Sprint end, and those tickets removed from the Sprint during the duration of the Sprint.

Related metrics

Sprint Target Completion is often used in conjunction with Sprint Work Added Completion (%) and Sprint Completion (%).

As the name suggests ‘Sprint Work Added Completion’ looks at the percentage completion of those tickets that were added during the sprint itself. Adding tickets after the Sprint has started is not ideal (and often results in poor/reduced Sprint Target Completion) but it is often inevitable. The key is to minimise the fluidity of scope. As such, Sprint Work Added Completion is an important additional metric to track how prevalent the practice is and to monitor the Scrum team’s ability to complete this additional work during the duration of the sprint.

Sprint Completion is the other Sprint metric often considered in conjunction with Sprint Target Completion. It is important as it shows the overall ability of the Scrum Team to hit their Sprint goals having taken into account work added after the Sprint has started.

Key use cases

Sprint Target Completion is a Scrum metric that becomes second-nature to high-performing Scrum teams. It should sit at the heart of team stand-ups, Sprint planning and Sprint retrospectives to constantly track and review the team’s ability to deliver their Sprint goals and hence to become a dependable Scrum Agile delivery capability.

Sprint Target Completion is also highly relevant when viewed at an aggregate level across multiple Scrum teams (or Release Trains); and when averaged over longer time periods (e.g. Programme Increments). At an aggregate level, Sprint Target Completion informs the delivery leadership team when they are required to make delivery commitments to the wider organisation and as a key input into programme planning and progress reporting.

Key uses cases of Sprint Target Completion are:

  1. Immature Scrum Teams starting out with a Scrum Agile methodology and looking for a core metric to track their growing effectiveness over time
  2. High-performing, mature Scrum Teams focused on consistently improving their delivery velocity and dependability
  3. Larger (e.g. Scaled Agile) delivery environments where individual Scrum teams need to work together to deliver a shared objective. This may involve many interdependencies between teams across multiple Sprints. Hence dependability of teams becomes critical to:
    • avoid delays and time wasted as one team waits for another team to complete its work
    • have any chance of delivering the overall delivery objective within the planned timeframe.

Expected outcomes

By increasing Sprint Target Completion to 90% or higher, delivery teams should expect to see the following outcomes:

  1. A clear improvement in Scrum teams’ ability to hit medium-term and longer term delivery goals (and hence happier internal customers)
  2. A gradual increase in velocity and throughput as the dependability of the team starts to pay dividends and teams have the confidence to set slightly larger sprint goals
  3. Increased morale within the team (as process inefficiencies and sprint failures are detrimental to team morale)
  4. Stronger collaboration between teams and increased awareness of the delivery objectives of the team and internal customer needs.

Plandek Metric of the Week: Delivery Lead Time

Metric Definition

Delivery Lead Time (or ‘Lead Time’) is a core agile software delivery metrics (alongside Cycle Time) which tracks an organisation’s ability to delivery software early and often. The concept of Lead Time is borrowed from lean manufacturing.

Lead Time refers to the overall time to deliver an increment of software from initial idea through to deployment to live – i.e. the complete end-to-end software delivery life cycle (SDLC).

Whilst Cycle Time is a subset of the overall delivery time, typically measured as the time from the start of work (development) until deployment to live (traditional Cycle Time) or from code commit to production (sometimes referred to as Code Cycle Time).

A Lead Time can be calculated for any increment of work – e.g. story, task, bug.

The example below shows Lead Time for stories and so relates to the time taken to deliver new features. As the chart shows the total Lead Time is 11 days which is actually very good and represents the time taken for a ticket (story) to leave the backlog until deployment to live.

Example software delivery Lead Time summary chart – Plandek Value Delivery Efficiency dashboard

 

Example Lead Time status review chart – Plandek Value Delivery Efficiency dashboard

 

As shown in the expanded view of Lead Time in the Lead Time Status Review chart above, analysis of Lead Time should become an integral part of effective agile software delivery.

The chart shows the active and inactive status groups and the time stories spend in each status across the total 11.3 day Lead Time.

If ticket statuses have been sensibly defined in the issue tracking (workflow management) tool such as Jira – then delivery Team Leads and

Delivery Managers can use Lead Time analysis to see where tickets are getting ‘stuck’ in the process.

In the example above, the inactive statuses such as ‘Ready for Development’ account for a relatively large proportion of the overall Lead Time (5.6 days), hence there is friction in the process and there is scope to reduce the overall Lead Time and thereby increase software delivery velocity.

Related metrics

Lead Time is often used in conjunction with other flow metrics such as Cycle Time and Flow Efficiency. Similar to Lead Time, Flow

Efficiency analyses in more detail the flow of work throughout the end-to-end delivery lifecycle, and reflects the proportion of time that a ticket is actively being worked on by the team versus the time it is stalled in some form of a queueing state (e.g. To Do, Pending QA, Pending Sign-off). In other words, it represents the time a ticket was actively being worked on as a percentage of the total time (i.e. Lead Time).

Flow Efficiency is expressed as a percentage of the overall delivery time. It enables teams to quickly pinpoint stages in the delivery process where excessive friction or “waste” exists. By reducing the process “waste” and time spent in a queueing state, teams can quickly and quite dramatically increase their time to market and throughput without the need to increase headcount.

Key use cases

Delivery Lead Time is often used as a critical ‘North Star’ metric around which to drive the continuous improvement of the software delivery team and to encourage teams, squads and tribes to remain focused on satisfying their internal customer demands by delivering value as quickly and efficiently as possible.

Helpfully Lead Time can be tracked at all levels within the delivery capability – it is very useful at team level to identify and remove delivery bottlenecks – but it is also very useful to track over time at an aggregate level, to track improvement in the overall effectiveness of an organisation’s software delivery capability.

Analysis of Lead Time is therefore a key agile delivery metric for any software delivery team looking to improve delivery efficiency and throughput.

Key uses cases of Lead Time are:

  1. Teams looking to take an end-to-end view of the SDLC, from ideation to deployment, in order to really understand where friction may lie
  2. Teams that are looking to increase speed to market and increase throughput or velocity
  3. Teams looking to identify bottlenecks in the software delivery process, particularly as they grow in size and complexity
  4. Teams looking to mature their Agile DevOps capability and continuously improve their delivery effectiveness around some simple Agile delivery metrics (KPIs).

Expected outcomes

By reducing Lead Time, delivery teams should expect to see the following outcomes:

  1. A reduction in time to market for new functionality (evidenced in Lead Time and Cycle Time)
  2. An improvement in overall throughput (e.g. a Scrum team’s increased velocity)
  3. A reduction in resolution time for bugs
  4. Increased morale in the team (process inefficiencies are detrimental to team morale)
  5. Stronger collaboration amongst team members and increased awareness of the delivery objectives of the team and internal customer needs.

 

Plandek Metric of the week: First Time Pass Rate

First Time Pass Rate (%) is an excellent measure of overall team health. As the name suggests, it measures the percentage of tickets that pass QA first time (without stimulating a return transition or defect sub-task). Too often this metric is seen as an engineering quality metric, when indeed it is a better reflection of how well a team is working together and supporting one another.

A pass first-time requires the inter-dependent elements of an agile development team to be working well:

  • strong collaboration and communication between team members throughout the delivery process
  • well-defined tickets that are clearly understood by developers and QA testers
  • reduced WIP levels, allowing engineers to focus on a single ticket at one time
  • a well-supported QA process that’s engaged throughout the process and clear on the functionality that needs to be tested

Only when all these things are in place, will First Time Pass Rate be optimised. As such, it is a good overall Agile software delivery KPI.

First Time Pass Rate is often considered in tandem with a similar quality metric, Return Rate (%). The exact definition of both these software delivery metrics are shown below:

Example Flow Efficiency summary chart – Plandek Value Delivery Efficiency dashboard

As shown in the example First Time Pass Rate summary chart below, First Time Pass Rate can easily be tracked over time as part of an ongoing continuous improvement initiative.

It is a powerful software delivery metric as it is meaningful when aggregated (e.g. at tribe, programme, release train level). It is also critical at delivery team level and should become a core agile metric for review in team retrospectives and other team effectiveness and planning meetings.

Example First Time Pass Rate summary chart – Plandek Value Delivery Efficiency dashboard

Example First Time Pass Rate drill-down chart – Plandek Value Delivery Efficiency dashboard

A software delivery and engineering metrics platform like Plandek enables you to drill-down into a metric like First Time Pass Rate to see trends over time, the tickets themselves that regressed and variations in First Time Pass Rate at key stages in the delivery process (e.g. QA).

First Time Pass Rate when considered at individual engineer level should never be used as a performance review metric – rather it is a critical team metric as it is influenced by so many factors beyond the individual engineer’s control.

Related metrics

First Time Pass Rate is often considered with the similar and related quality metric Return Rate. Return Rate (%) tracks the overall percentage of tickets returned from QA. This may include tickets that have been returned multiple times.

As discussed above, First Time Pass Rate is most illuminating when viewed in tandem with other delivery metrics relating to the effectiveness of the team – as it is so affected by interdependencies within the team. Other relevant team metrics include:

  • Measures of backlog health such as Story Points Ready For Dev
  • WIP (the number of work items started but not completed at any one time)
  • Sprint completion % – a measure of the overall dependability of the team and its ability to hit its sprint goals

Key use cases

First Time Pass Rate is typically used as an agile delivery quality metric, particularly at the team level. As described, it is an excellent measure of overall team and process health and acts like the ‘canary in the coalmine’ in that it is a good leading indicator of underlying issues in team and process health.

As such it is often used within a broader balanced scorecard of agile delivery and engineering metrics to track Agile DevOps maturity.

Expected outcomes

By improving First Time Pass Rate you will see an immediate improvement in throughput (reduced Cycle Time) and a likely indirect positive impact on sprint completion and team morale.

A First Time Pass Rate of over 90% is achievable by mature Agile DevOps practitioners and high-performing teams.

Conversely, teams with low average First Time Pass Rate will struggle to deliver effectively – with longer Cycle Times, larger QA resource requirements and frustrated engineers.

About Plandek

Plandek works by mining data from toolsets used by delivery teams (such as Jira, Git, CI/CD tools and Slack), to provide end-to-end delivery metrics/analytics to optimise software delivery predictability, risk management and process improvement.

Plandek is a global leader in this fast-growing field, recognised by Gartner as a top nine global vendor in their DevOps Value Stream Management Market Guide (published in Sept 2020).

Plandek is based in London and works with clients globally to apply predictive data analytics and machine learning to deliver software more effectively.

Plandek Metric of the week: Flow Efficiency

Flow Efficiency is one of the most powerful metrics to help you improve the efficiency of your software delivery process. As the name suggests, it analyses the flow of work throughout the end-to-end delivery lifecycle, and reflects the proportion of time that a ticket was actively being worked on by the team versus the time it was stalled in some form of a queueing state (e.g. To Do, Pending QA, Pending Sign-off). In other words, it represents the time a ticket was actively being worked on as a percentage of the total time (i.e. Lead Time).

Flow Efficiency enables teams to quickly pinpoint stages in the delivery process where excessive friction or “waste” exists. By reducing the process “waste” and time spent in a queueing state, teams can quickly and quite dramatically increase their time to market and throughput without the need to increase headcount.

Example Flow Efficiency summary chart – Plandek Value Delivery Efficiency dashboard

Sample Flow Efficiency summary chart – Plandek Value Delivery Efficiency dashboard

The Flow Efficiency status review chart identifies all the inactive and active statuses that tickets pass through within the issue management system (such as Jira or Azure). The illustrations above show just how easy it is for Teams to identify the bottlenecks and other “waste” within their delivery process and look to implement the corrective actions that will improve Flow Efficiency.

Related Metrics

Flow Efficiency is very often used in conjunction with analysis of Cycle Time and Lead Time as organisations look to improve the overall effectiveness of their software delivery capability. Lead Time and Cycle Time are two of the ‘North Star’ agile delivery metrics which track an organisation’s ability to delivery software early and often.

Lead Time refers to the overall time to deliver an increment of software from initial idea through to deployment to live – i.e. the complete end-to-end software delivery process. Whilst Cycle Time is a subset of the overall delivery time, typically measured the time from development start to live (traditional Cycle Time) or from code commit to production (sometimes referred to as Code Cycle Time).

Key Use Cases

Analysis of Flow Efficiency is a basic first step for any delivery team looking to improve delivery efficiency and throughput.

So key uses cases are:

  1. Teams that are looking to increase speed to market and increase throughput or velocity
  2. Teams looking to identify bottlenecks in the software delivery process, particularly as they grow in size and complexity
  3. Often Flow Efficiency analysis is used when Cycle Time and Lead Time are being introduced as key overall software delivery efficiency metrics, as part of a broader move to more data-driven software delivery

Expected Outcomes

By increasing Flow Efficiency, you should expect to see the following outcomes:

  1. A reduction in time to market for new functionality (evidenced in Lead and Cycle time)
  2. An improvement in overall throughput (e.g. a Scrum team’s increased velocity)
  3. A reduction in resolution time for bugs
  4. Increased morale in the team (process inefficiencies are detrimental to team morale)
  5. Stronger collaboration amongst team members

Plandek

Plandek works by mining data from toolsets used by delivery teams (such as Jira, Git, CI/CD tools and Slack), to provide end-to-end delivery metrics/analytics to optimise software delivery predictability, risk management and process improvement.

Plandek is a global leader in this fast-growing field, recognised by Gartner as a top nine global vendor in their DevOps Value Stream Management Market Guide (published in Sept 2020).

Plandek is based in London and works with clients globally to apply predictive data analytics and machine learning to deliver software more effectively.

While the key objective of the Agile software development is the early and continuous delivery of valuable software, it can be difficult to really know if you’re successful.

We think the trick is finding a simple set of four metrics your teams understand and trust in order to deliver rapid, sustainable and significant improvement in your delivery outcomes.


 Find out how Plandek can increase YOUR Velocity by 75%. Book a demo now.


We call these critical metrics ‘North Star’ metrics – they set the direction for the whole engineering organisation. They need to be carefully selected to be meaningful when aggregated and illustrative of effective software delivery. The four key metrics provide a rounded view of your software development process:

Figure 1. Top 4 ‘North Star’ Agile Delivery Metrics

1. Cycle Time is a crucial metric for all engineering teams. It measures the time from starting work on a feature or bug until it’s in production. Unlike the broader measure of Lead Time which includes the time spent in product refinement and on the backlog, Cycle Time is easier to influence as it looks only at the time which is in the control of the team.

The Cycle Time metric view allows teams to understand time spent in each ticket status within the development cycle. Plandek has flexible analytics capability and powerful filtering to allow analysis by Status, Issue Type, Epic (and any other standard or custom ticket field) all plotted over any time range required.

Figure 2. Example Plandek Cycle Time metric view

2. Deployment Frequency is another fundamental measure of an organisation’s ability to rapidly deliver value. Key to achieving the Agile objective of rapid and continual delivery of software is is developing the capability to develop and deploy small software increments rapidly. Deployment Frequency tracks that competence and is a powerful metric around which to focus effort at all levels in the delivery organisation.

3. Delivered Story Points is often considered a problematic metric due to the potential inconsistencies in the calculation of story points and how much effort they represent. However, as a basic measure of output and how that is trending over time, it is a powerful metric around which to align.

There may be concerns of teams ‘gaming’ the metric with story point inflation, but as with all metrics, they should be viewed in context by experienced folks who know the teams well. It is also not large numbers of story points that signify success, but consistency.

And finally, 4. Escaped Defects is a simple but effective measure of overall software delivery quality. It can be tracked in a number of ways, but typically teams use either a priority or label on bugs.
When these four simple Agile delivery metrics are viewed together, you get a balanced view of how your organisation is doing at building software and you can use them to underpin a powerful continuous improvement process at team level.

Using the Top 4 Agile delivery metrics to increase Velocity by 75% and Deployment Frequency by 15%

This metrics-led approach to continuously improving Agile delivery effectiveness can be highly effective.

A major Plandek enterprise client in the travel technology sector uses Plandek to underpin a metrics-led approach to continuously improving their software delivery process. As a result, over the past 24 months, using a simple set of Agile delivery metrics surfaced in Plandek’s customisable dashboards, the client has:

  • Reduced Cycle Time by 75%
  • Reduced hot-fixes in production by 54%
  • Doubled commit frequency by Engineers
  • 15% average increase in deployments per day.

Start your super-easy sign-up journey here >

Or, find out how Plandek can increase YOUR Velocity by 75%. Book your demo now.</s

Cycle Time is a critical Agile software delivery metric. It tracks the time taken from work starting on a piece of work until it meets the Definition of Done and helps you to identify bottlenecks in your software development process – this will help you increase velocity, throughput and allow work to flow much more smoothly.

Therefore, Cycle Time should be adopted as a key focus for delivery teams, but cycle time in Jira dashboards and other analytics tools don’t tell you the whole story. In many teams, there is a lot of work that happens outside of Jira, for example, code review and deployment processes. Plandek traces your work from idea to deployment and end to end traceability is vital to optimise your end to end development process.

Plandek provides customised Jira dashboards and Jira reports (combining data from Jira, Git, and CI/CD tools), to allow development teams to closely analyse their own Cycle Time and understand where in the Cycle Time there is an opportunity to drive down time to value.


Do you want to increase your Agile software delivery velocity by 25%? Book your demo now.


As you can see in figure 1, Plandek’s Cycle Time metric allows teams to understand the time spent in each stage of the development cycle. The flexible analytics capability and powerful filtering allow breakdown and filtering by Status, Issue Type, Epic (and any other standard or custom ticket field) all plotted over any time range required.

Figure 1. Example Plandek Cycle Time metric view

Delivery Team Leads can analyse their team’s Cycle Time to see where time is spent and bottlenecks may lie.  If the workflow has been well defined in Jira, it is easy to see the proportion of time spent in ‘active’ Jira statuses versus ‘inactive’ Jira statuses within the total Cycle Time using Plandek.

Inactive Jira ticket statuses like “Ready for QA” can be analysed to identify the scope for saving time,  thereby increasing delivery velocity (and reducing the Cycle Time).  Very often the Cycle Time can be significantly reduced without increasing team resources, simply by removing avoidable bottlenecks.

Delivery metrics and engineering metrics that affect Cycle Time

Plandek’s Customer Success team works with the software delivery team to identify key delivery metrics and engineering metrics that have the biggest impact on reducing Cycle Time without impacting software delivery quality or requiring additional resource allocation.

Analysis shows three delivery metrics and engineering metrics that could unlock significant shortening of Cycle Times across almost all scrum teams.  These delivery metrics are not available in standard Jira reporting or Jira dashboards but are available in Plandek’s  customisable dashboards.  These are:

  1. Flow Efficiency (which looks at the proportion of time tickets spend in an ‘active’ versus ‘inactive’ status)
  2. Mean Time to Resolve Pull Requests (hrs)
  3. First Time Pass Rate (%).

Using Cycle Time analysis to increase velocity by 25%

This data-driven approach to continuously improving Cycle Time can be highly effective.

One of Plandek’s clients set an OKR to improve cycle time and achieved a 25% improvement in Cycle Time over the following 6 months in their development team of 2,500 software engineers through the use of Plandek in each team’s daily standups and sprint retrospectives.

Using Plandek, four delivery metrics and engineering metrics were found to directly impact Cycle Time across multiple teams: Flow Efficiency (which looks at the proportion of time tickets spend in an ‘active’ versus ‘inactive’ status);  Mean Time to Resolve Pull Requests (hrs); First Time Pass Rate (%); and Story Points Ready for Development.

Get started for free

Plandek Teams brings the power of Plandek’s enterprise-level end-to-end delivery and engineering metrics to smaller delivery teams.

Create your account and unlock immediate insights via our customisable dashboards.


Start your super-easy sign-up journey here

To increase your Agile software delivery velocity by 25% Book your demo now.

Plandek, the fast-growing data analytics provider for the end-to-end software delivery process today announces the launch of Plandek Teams and Plandek Teams Starter – to bring Plandek’s powerful enterprise-level analytics to smaller delivery teams for the first time.

2021 will be the year that DevOps Value Stream Management (VSM) goes mainstream – with organisations large and small recognising the need to more effectively manage the end-to-end software delivery process, to deliver quality software faster and more predictably.

As a global leader in end-to-end software delivery metrics and analytics, Gartner recently recognised Plandek as a top nine global vendor in the fast-moving Value Stream Management (VSM) space – as they deem end-to-end analytics a critical element of effective VSM.

To date, Plandek’s powerful analytics have only been available to enterprise customers.  Now, with the launch of Plandek Teams and Plandek Teams Starter, the power of Plandek is available for smaller software delivery teams for the first time:

  • surface critical Agile delivery, engineering and DevOps metrics in customisable Jira dashboards with powerful drill-down and trend analysis
  • super-easy online sign-up to create your own customisable Jira dashboards
  • Plandek Teams Starter is free for 1 Jira Board with Plandek Teams starting from $99 per month for larger deployments (up to a maximum of 4 Jira Boards and 10 code repos)
  • integrates with Jira, code repos and CI/CD tools like Jenkins to synthesise data critical to understanding your end-to-end delivery effectiveness.

Plandek Teams is perfect for organisations with small scale delivery teams to:

  • shorten time to market and increase the velocity of software delivery
  • deliver software more predictably (to avoid costly go-live delays)
  • drive the quality of the software delivery process and the software delivered
  • embed a culture of continuous improvement around a meaningful set of metrics, in order to drive improved efficiency and team health over time.

Dan Lee, Co-CEO of Plandek comments: “We are delighted to launch Plandek Teams, which brings the power of Plandek’s enterprise level end-to-end delivery analytics to smaller clients for the first time.  It’s super-easy to get started, great value and has the power to help you transform software delivery outcomes.”

Charlie Ponsonby, Co-CEO Plandek adds: “Plandek Teams offers the world’s most powerful Jira dashboard, so all organisations can apply enterprise-level data analytics – to reduce time to value and greatly improve delivery quality and predictability.”

  

About Plandek

Plandek works by mining data from toolsets used by delivery teams (such as Jira, Git, CI/CD tools and Slack), to provide end-to-end delivery metrics/analytics to optimise software delivery predictability, risk management and process improvement.

Plandek is a global leader in this fast-growing field, recognised by Gartner as a top nine global vendor in their DevOps Value Stream Management Market Guide (published in Sept 2020).

Plandek is based in London and works with clients globally to apply data analytics to deliver software more effectively.

 

For enquiries please contact Dieter Danner: ddanner@plandek.com