The effectiveness of an IT team directly impacts a company's success, but measuring that effectiveness can be really difficult. Counting output is tempting and simple, but that is not what really works with software, because our tasks are mostly unique and require a creative approach. Developers can fix a single bug both in 10 lines of quality code or write a hundred lines and accidentally create a technical debt. Ticket counts and lines of code encourage ‘closing for the record’ rather than closing for value. As the CTO of a global gifting marketplace Flowwow, I mostly rely not on vanity data, but on those metrics that measure the result and its value to the business. Thus, I can feel the team health, conduct in-depth performance reviews, and track growth. team health in-depth performance reviews track growth The Two Metrics To Track Productivity The Two Metrics To Track Productivity To get the most of my teams' work, I mostly rely on Cycle Time and Story Points. The first shows me how quickly we're delivering value, and the second helps the team to estimate complexity of the work ahead. Measure Flow, Not Hours Cycle Time is the time from starting work on a ticket or task to the change being deployed to production. Cycle Time Cycle Time The Cycle Time calculation consists of: calculation calculation Grooming: Defining the task and estimating it in Story Points.
Coding: The actual writing of the software.
Code Review: Peer or team lead review of the written code.
Testing: Checking for bugs and overall functionality. Grooming: Defining the task and estimating it in Story Points. Grooming: Coding: The actual writing of the software. Coding: Code Review: Peer or team lead review of the written code. Code Review Testing: Checking for bugs and overall functionality. Testing: Every company has its own ideal targets. At Flowwow, for instance, teams with highly optimised value delivery processes hit around 10–11 days. Our average teams typically take 11–15 days to implement a solution. If it's more than 15 days, then, probably, it’s time to overlook the flow or pay attention to the team’s moods. own ideal targets. own ideal targets. I remember reading about a large tech company that wanted to boost developer output without sacrificing quality. They implemented the SPACE framework and focused on reducing Cycle Time. By improving code reviews and automating testing, they saw their average Cycle Time drop from 8 to 6 days in just six months. As a result, a 30% reduction in customer-facing defects and a huge jump in satisfaction rates. 30% reduction in customer-facing defects reduction reduction Focus On Complexity Story Points are our way of estimating the relative complexity of a task. This assessment is given by the team collectively during the grooming phase, before coding begins. Instead of trying to guess how many hours a task will take (a game everyone loses), developers compare tasks to build a complexity score. Usually, Story Points are estimated similar to the Fibonacci sequence: 1, 2, 3, 5, 8, 13, etc – the higher the number, the harder the task. Story Points Story Points compare tasks to build a complexity score compare compare The estimate takes into account: The estimate takes into account: The sheer volume of work.
Any uncertainty in the requirements.
Potential risks.
The core technical difficulty involved. The sheer volume of work. Any uncertainty in the requirements. Potential risks. The core technical difficulty involved. This method helps to understand how much work the team can realistically take on in an upcoming sprint. Crucially, it’s low-stress because the estimates are collaborative and non-punitive. Developers focus on writing the code, and managers get a clearer picture of the team’s capacity with an ability to optimize processes when needed. how much work the team can realistically take on I believe that breaking down large tasks is what makes a huge difference in productivity and spirits. Split it into smaller, manageable milestones, so the developer can see the results more frequently. Split it Split it the developer can see the results the developer can see the results Usually, the total number of closed Story Points per month is pretty predictable for the whole team and for each developer. So, if I get the numbers that are lower than expected, it's a warning flag to me. Is everything fine with the person or the spirits in the team? Checklist: How To Interpret Metrics Wisely Checklist: How To Interpret Metrics Wisely When it comes to measuring effectiveness, there’s one final point to highlight: Context is often more important than the numbers themselves. It’s easy to look at metrics and jump to a negative conclusion when something goes wrong. But the 'low' volume developer might be the one tackling the most ambiguous, complex tasks or spending crucial time mentoring others. The real lesson is that a metric should always become an opportunity for support and discussion about balancing the workload. Here’s my checklist for an honest measurement system: checklist checklist Start with a problem: what do we want to improve?
Separate metrics from rewards: your performance metrics must not directly influence a developer's income. Good programmers will simply game the numbers.
Automate data collection, because no one likes complex bureaucracy for the sake of bureaucracy.
Make dashboards transparent for the whole team, and highlight it’s all done for the team itself.
Always look behind the numbers for the context.
Review your metrics with the team regularly.
Overlook the environment within the team. People achieve more when they are surrounded by supportive and friendly professionals. Start with a problem: what do we want to improve? problem Separate metrics from rewards: your performance metrics must not directly influence a developer's income. Good programmers will simply game the numbers. Separate metrics from rewards Automate data collection, because no one likes complex bureaucracy for the sake of bureaucracy. Automate data Make dashboards transparent for the whole team, and highlight it’s all done for the team itself. dashboards transparent Always look behind the numbers for the context. look behind the numbers Review your metrics with the team regularly. Review your metrics Overlook the environment within the team. People achieve more when they are surrounded by supportive and friendly professionals. environment within the team Make a transparent system that is interpreted with context and is based on mutual respect and focus on value. Add engaging tasks and supportive colleagues. That’s how a strong performing team is done.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

KPIs Are Destroying IT Teams: How to Actually Measure Developer Performance

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

17 Ways to Motivate Your Dev Team

3 Must Have Practices for Distributed Developers

[Top 3] Time Management Habits of Highly Productive Distributed Teams

4 Tips to Improve Your Engineering Team's Velocity in Scrum

7 Software Development Methodologies Loved by Enterprises in 2022

Insights to Agile Methodologies for Software Development

17 Ways to Motivate Your Dev Team

3 Must Have Practices for Distributed Developers

[Top 3] Time Management Habits of Highly Productive Distributed Teams

4 Tips to Improve Your Engineering Team's Velocity in Scrum

7 Software Development Methodologies Loved by Enterprises in 2022

Insights to Agile Methodologies for Software Development

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps