Your software project is running months behind schedule. The development team originally estimated that it would take three months to build and you’re already in the fifth month with nothing to show. You’re frustrated by the moving goalposts and the developers are frustrated with the mounting pressure.
Software development is notoriously difficult to measure. While a building contractor or auto mechanic can provide a reasonable estimate, software developers face a lot of unknowns. The desired functionality may evolve over time and unexpected technical challenges or bugs can significantly delay projects.
In this article, we will look at how to effectively measure development projects, set the right expectations, and start delivering results on time.
Software development is notoriously difficult to measure without laying some ground rules. Click To TweetHow Fast Is Fast Enough?
You know that your development team isn’t moving fast enough, but how exactly do you define “fast enough”?
Many product businesses measure progress using throughput while service businesses often look at man-hours. Unfortunately, software development isn’t so simple. You can’t look at the number of lines of code committed or the number of hours worked and receive a true gauge of progress.
For example, the same developer could spend one hour writing 1,000 lines of basic HTML or one hour implementing a complex 25 line algorithm. The HTML could have very little business value relative to the complex algorithm. So, how do you measure progress when dealing with this kind of variability?
How to Measure Velocity
Agile projects measure progress by assigning arbitrary points to a piece of functionality. These points estimate the amount of complexity and the size of the code changes required to deliver a unit of functionality. We look at user-visible functionality, but there are many different approaches to using these points.
The project’s velocity is calculated by dividing the calendar into sprints and totaling the points delivered and accepted in the previous cycle. By averaging these figures over several sprints, the velocity of the project becomes apparent and provides a baseline for measuring progress.
Many Agile development teams use point tracking systems to measure project velocity over time. For example, Pivotal Tracker’s Burndown Charts show the amount of work left to do over a period of time, which demonstrates the velocity of a project and helps predict when work will be completed.
How to Interpret Velocity
Velocity measures work best with stable teams that have been working together for a long time. If you have frequent turnover, velocity measures become a lot less meaningful. The same is true if your product backlog is missing user stories, since there’s effort made by the team that isn’t being reflected.
Over time, there is a correlation between points and time spent within a given team and project. The velocity may change over time depending on expertise, morale, complexity, and other external factors. It also generally decreases over time as the project grows in scope and new changes require more effort.
It’s tempting to increase velocity by increasing personnel, but that’s not always the case. The impact of adding people to a project or team depends on how much communication must take place between team members. Teams with minimal interdependence can effectively increase velocity by adding team members.
Are You Compromising Quality?
Quality problems are extremely expensive to fix, but how do you measure the quality of your code base?
There are many potential sources of quality issues: Your team may lack the expertise to execute certain types of projects, or workplace dynamics may cause poor morale. Managers can also influence quality by making poor architectural choices or pushing the team to develop at an unsustainable pace.
How to Measure Code Quality
We measure quality problems in terms of the number and severity of bugs or defects.
Most software teams have some system in place to categorize these bugs as Critical, Urgent, Low Priority, etc. While this makes it easy to reduce quality issues into a quantifiable number, it assumes that all defects have been found and categorized accurately, which is not always the case.
There’s also a subjective component to quality. For instance, a software project may technically meet a set of acceptance criteria, but it may not have a very good user experience. We tend to break down this “polish” into Prototype, Internal, B2B, and Consumer levels on a one to five scale.
The level of subjective quality required depends on the end market. In general, internal systems may be fine with a 1 or 2 polish level while consumer-facing software may require a 4 or 5 polish level. The quality of the user experience can have a tremendous impact on the success of a project.
How to Improve Code Quality
Quality assurance teams are instrumental in identifying all defects and accurately categorizing them. Dedicated QA teams should be involved early in the development process to catch requirement defects before they reach developers, but everyone should be looking for these kinds of issues.
Processes should be in place to help ensure a high level of quality, too. For example, code reviews, staging servers, acceptance processes, code merge procedures, and continuous integration are all essential tools to avoid bugs being introduced into production environments.
Technical and architectural choices can also have a large impact on code quality. For example, the use of unproven open source modules in software projects involves the risk of these modules failing in terms of maintenance.
Are You Still Falling Short?
AELOGICA specializes in long-term team augmentation to assist existing development teams struggling to meet deadlines and maintain code quality. We work especially well with established and growing businesses with large code bases or multiple applications that they’re responsible for maintaining.
We provide a mix of development, design, and quality assurance personnel, depending on your needs. Our developers also meet for “daily stand ups” via video conferencing with product managers or other stakeholders. Our goal is to become an extension of your internal team to help scale or provide expertise on demand.
If your existing development team is falling short, our 10X Dev Academy is designed to teach the non-technical skills needed to become a great software developer. We offer team licenses designed to improve your overall team dynamics and productivity.
For more information, contact us for a free consultation and learn how we can help you make measurable progress today!