How do you measure productivity? It is a question that keeps coming up for everyone involved in software development, from CEOs to coders to project managers. And after more than 14 years at Scio, I can tell you that the answer has changed significantly, and still nobody agrees on the perfect method.
Let me walk you through how I think about it, where the common approaches fall short, and why I believe software development productivity is ultimately about the value delivered to the people using the software, not about counting what the team produced along the way.
Table of Contents
Where the Old Productivity Metrics Come From
At the end of the 1990s, a methodology called Personal Software Process, or PSP, was designed to help developers measure their productivity. You had to take a course, follow detailed documentation, and use a timer to measure your progress, stopping it every time you needed a coffee or a bathroom break. The idea was solid in concept: measure how much you accomplish in a day. The problem was that it tied productivity too closely to lines of code written. The more you coded, the more productive you were, which is not necessarily true.
Maybe that logic made more sense in an era without frameworks, when you coded every piece of a product from scratch. Today you can produce the shell of a website in minutes without writing a single line directly. The tools have changed completely, but I still see organizations falling back on counting outputs. That concerns me.
What Productivity Actually Means in Software
I define productivity as finishing a task in a reasonable time. The word "finishing" is key because productivity is not starting a lot of things. It is seeing a project through to a working product. But here is where it gets complicated: how do you define "finished" in software?
If you are building something physical, like a boat, the phases are clear and requirements are documented. Software development does not work that way. There is an artisanal quality to it. Everyone has their approach and style, and the dynamics of a team change significantly depending on who is in it and what they are building. I have seen this firsthand across hundreds of projects at Scio. No two teams reach the same definition of done the same way.
Why Traditional Metrics Fall Short
Ask a room full of developers how many lines of code they write to measure productivity and you will get a heated discussion. The best code is concise and understandable by anyone reviewing it. A developer writing 10,000 lines to accomplish what another achieves in 500 is not more productive. They are solving the same problem less efficiently.
| Approach | How It Works | Risks | Best For |
| Lines of Code | Measures output by lines a developer writes | Produces bloated code, encourages gaming the metric | Legacy systems, basic scripting |
| Velocity / Story Points | Tracks work completed per sprint in Agile | Can be manipulated, does not always reflect user value | Agile teams, iterative development |
| Value Delivered (Scio Model) | Measures impact, quality, and stakeholder feedback | Requires alignment and communication to work well | Nearshore teams, complex or evolving products |
If a company gives productivity bonuses based on lines of code, developers will find ways to inflate those numbers. You end up with bloated, inefficient products. I have seen it happen. You have to be very careful when linking rewards to metrics, because the wrong metric creates a perverse environment where everyone is racing to look productive rather than to build something useful.
The Scio Approach: Value as the Core Measure
Since Agile methodologies arrived, software development productivity at Scio has moved away from counting lines of code toward understanding how that code comes together to produce working software. The shift is more significant than it sounds.
Not long ago, project requirements were written from the perspective of the system: "The system shall do X. The system shall do Y." You ended up with a massive document repeating that phrase for every behavior. Then the Agile movement recentered on the user: "The Administrator can do this. The Manager can do that." We understood that software is about what people in different roles can accomplish, not about a system performing actions.
At Scio, we look at productivity from the perspective of the stakeholders and clients we are building for. We measure it through information we get from them: how our teams are doing, how much value they are adding, and what their perception of the overall process is. We developed internal tools like the Team Self-Assessment, a questionnaire that helps teams examine what matters most: quality practices, code review habits, pair testing, documentation discipline, and whether they are focusing attention on the right issues.
How Software Development Works by Evolution
It is often said that only around 35 percent of software development projects succeed. I think a big part of that has to do with rigidity in the planning stage. If you plan to complete phases A, B, and C in six months but it takes eight, does that two-month difference mean the project is failing? In my experience, not necessarily.
This happens often with startups building something genuinely new. In the course of development, a feature sometimes reveals potential that was not visible at the beginning. The plan has to be reworked to capture that value. If you measure productivity very rigidly, and then that same process surfaces unexpected value that forces a rework, it is easy to label it as failure when it is actually discovery.
This is why at Scio we step back from pure technical metrics and focus on the business side of things: having conversations with stakeholders, understanding what the business actually needs, and figuring out which features matter most before the technical team starts sketching solutions. Industry research from McKinsey supports this view, showing that teams optimizing delivery through value-driven Agile practices consistently achieve higher speed, quality, and long-term stability.
What This Means for Engineering Leaders
CTOs at mid-market software companies
For the delivery conversation often surfaces when delivery feels slower than expected but the team appears to be working hard. That gap is almost always a measurement problem, not a people problem. When the metrics being tracked are velocity and ticket counts without any connection to user value or stakeholder feedback, leaders end up managing the wrong signal.mid-market software companies
Scio's dedicated nearshore teams bring the value-driven measurement model into engagements from day one, which helps align the delivery conversation with business outcomes rather than output volume.
PE-backed software portfolios
For PE-backed software portfolios productivity measurement is a portfolio-level governance question. When each PortCo tracks different signals disconnected from business outcomes, evaluating delivery health across the portfolio becomes a comparison of incompatible numbers. The most useful model I have seen combines delivery signals with direct stakeholder feedback and team health indicators. If you want to discuss how this works in practice, our team at Scio would be glad to talk.
Frequently Asked Questions
Why is measuring software development productivity so difficult?
Because software development is not repetitive or linear. Every team, product, and problem space is different. Unlike manufacturing, software work varies widely in complexity and evolves as the product is built, making one-size-fits-all metrics unreliable. The methodology that worked for one team and codebase may be completely wrong for another.
Are lines of code a reliable indicator of developer productivity?
Not in modern development. More lines of code typically mean more complexity, higher maintenance costs, and increased regression risk. Effective teams focus on clarity, stability, and value delivered, not code volume. The same feature written in 500 lines versus 10,000 lines represents the same user value but very different maintenance burden.
How does a value-driven productivity model work in practice?
Instead of measuring output, it evaluates impact: user value, product quality, stability, stakeholder feedback, and team alignment. This approach reduces waste and improves decision-making, especially in Agile environments where context changes frequently. At Scio, this means having direct conversations with stakeholders about what they perceive as valuable, not just what was completed in a sprint.
What is the risk of linking performance bonuses to productivity metrics?
The main risk is that developers optimize for the metric rather than the outcome. When bonuses are tied to lines of code, developers may write more verbose code. When tied to tickets closed, they may break work into smaller units to inflate the count. Any metric that becomes a target for incentives tends to become a poor measure of what it was originally tracking. The incentive structure needs to be aligned with the actual business goal.
A Question Still Being Answered
Considering all of this, forming an exact picture of software development productivity is still a question with no definitive universal answer. Every individual and every team has to decide what works in their specific context.
Whatever method you use, I think the Agile mindset got the direction right: the number of lines, the documentation volume, or how clean the database is matters far less than whether the software works for the people who need to use it. The most reliable measure comes from how well a team can deliver meaningful outcomes under real conditions. If you want to explore how this applies to your specific engineering organization, I would be glad to talk.
References and Further Reading
- McKinsey and Company, Yes, You Can Measure Software Developer Productivity. Research connecting value-driven measurement approaches to outcomes including reduced defects, improved employee experience, and higher customer satisfaction. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity
- Agile Alliance, Agile Manifesto and Principles. The foundational document establishing that working software and customer collaboration are more valuable than comprehensive documentation and following a plan. https://agilemanifesto.org/
- DORA Research Program, State of DevOps Report. Annual research connecting delivery practices including short cycles, feedback loops, and team health to measurable improvements in software delivery performance. https://dora.dev/publications/
- ACM Queue, The SPACE of Developer Productivity. Academic framework covering five dimensions of developer productivity including satisfaction, performance, activity, collaboration, and flow. https://queue.acm.org/detail.cfm?id=3454124
- Scio blog, Engineering Performance Framework: DORA, SPACE, and DevEx. Deeper analysis of the frameworks available for measuring software team performance beyond output-based metrics. https://sciodev.com/blog/engineering-performance-framework/