How to Measure and Estimate Software Development Productivity

While in most business spheres measuring software development productivity is a must and part of a normal operating procedure, for some reason it has become considered as a mythical, unreachable goal when it comes to software development. And even if software development is not your primary business, productivity measurement still may require your attention, e.g., if your company maintains a product catalog app or writes software product for back-office needs. Moreover, according to data provided by the United States Bureau of Economic Analysis, the investment of time and resources to software development is steadily increasing in the business sector overall.

Missed deadlines and over-budget projects can be clear indicators that the mechanisms a company uses to estimate the productivity of its software engineering projects contain weaknesses. Companies use input metrics such as estimating the resources necessary to dedicate to a project. I truly believe that using output metrics as additional metrics, i.e., the estimation of software functionality and quality achieved in a certain time period, may provide a more accurate assessment, and thus are worthy of measuring. Why this is so, how it is done, and ways to get started are covered here in today’s post.

Why does the majority of IT companies continue to use ineffective measuring methods?

Without evaluating a software development team’s productivity, companies end up operating blindly and dangerously gambling with their reputation and project budget. Nevertheless, many project managers continue to use an approach that doesn’t work effectively. The following are the most common reasons for this:

Changes require time to implement

Lack of time is the bane of the 21st century, and looming deadlines often make new initiatives impossible to implement. Yet, if all-night, last-minute work sessions become a developer’s routine, it is a sign that the project estimation procedure is crying for improvement, without which the productivity of your development will eventually decrease.

Changes require new procedures

Clearly, every new metric requires extra work to be tracked and measured. Moreover, a lot of software development companies have no systematized practices to calculate metrics or various development teams may be using different work environment and techniques on their projects — which all end up only further complicating output measurement.

Changes often meet resistance

To adopt a new procedure, companies need to demonstrate to their employees that it’s worth it, which can be difficult. Most likely, developers themselves — or anyone in general, for that matter — will by no means openly embrace additional means of measuring and monitoring their software development productivity. Consequently, a lot of companies give up on their search for applicable productivity metrics that would really end up increasing productivity.

As all the metrics output-based metrics have their benefits and drawbacks and can be challenging to implement, I assume the best solution to this problem is to blend UCs (use cases), is a list of steps, typically defining interactions between a role, an “actor” and a system, to achieve a goal, — with UCPs (use case points), a software estimation method used to forecast the software size for software development projects.

Let’s take a look at UC and UCP methods more closely.

Use Cases

Occasionally, companies can face difficulties in collecting and organizing the technical and functional requirements of software development projects, aside from not having practiced for calculating software development productivity in place. Some companies may list their requirements using so-called enumeration or to-do-list methods that have become deep-rooted habits that are challenging to modify. This may lead to difficulties in determining and meeting requirements, which in turn may trigger more last-minute change requests, issues with shifting priorities and, as an end result, disappointed customers.

Based on our experience, we have found that UCs provide an efficient and well-regulated approach to aligning the functional requirements of any software development project. Every single UC presents a scenario where the user of a software solution has interfaced with the application itself.

For instance, a use case for a hotel-booking app may describe each step that a customer has taken to evaluate various rooms, check their availability, choose one and make a reservation for it. In particular, use cases describe actors, the human users or systems that deal with the application at issue. They also show the way the application collaborates with the actors as well as how it performs a function. To clearly define a process, UCs can be arranged into subdivisions and sections.

A software solution’s functional requirements and business objectives take the leading roles in UCs. Design preferences and technical requirements can be built around use cases. This arrangement accelerates the requirements-defining phase of the software development process. Moreover, it mitigates the risk of failing to implement the required functionality and therefore can lower the number of hours for costly change requests or repairs necessary during the build phases. In addition, UCs also make it almost effortless to later develop functional test cases, consequently speeding up the testing process on the development backend.

Use-Case Points

UCPs are based on information collected in use cases. Use-case points arrive at a figure representing the number of transactions completed by a software solution and the number of actors that emerged with the application at issue. Then these raw calculations are tailored to the technical specification of the software solution and the line of code percentage is adjusted.

In general, the use-case point technique can be applied in less than a day, even for larger projects. You can start calculations early in the project development life cycle and adjust the results later on. UCPs can be used by a development team following agile approaches as well as a waterfall development model.

How to implement UCs and UCPs: Tips — and pitfalls to avoid

For smooth and painless implementation, choose the following carefully before you start:

• Tools for determining UCs and calculating UCPs;
• Ways to control the process and to display metrics.

Don’t start by all at once involving the entire software development department: first work with the most flexible teams that are focusing on new projects. Utilize finished projects as a means of training other teams to capture UCs and to calculate UCPs. When the results look promising, then shift to implementation for real on new projects.

It is also very important to never use your results to reward or penalize developers. The aim of measurement is to enhance time and resource estimates and improve planning — not to create stress on team members to the point that they may consider falsifying results in order to avoid poor performance outcomes.

On your mark

Like any changes, adopting UC & UCP practices may be challenging, yet the benefits they yield will be worth it. Even if you feel that the methods suggested in this post will not work in your particular situation, if your projects are frequently falling behind schedule don’t just leave this site and ignore the fact. There are myriad ways out there to accomplish this same result in improvement, and there’s certainly one that’s perfect for your teams and your company specifically.