In professional services, a fundamental responsibility that we have to our clients is that we accurately and honestly provide factual data to support the status and performance of our team, and the effort towards our planned goals. But how do we measure performance to get factual data that is relevant? What are the best metrics to track? What tools can I use today that weren’t available a few years ago? Read on to find out.
What are the “best” metrics to track?
At first glance, this seems like a pretty straightforward question, but let’s dive a little deeper by using this example: our stakeholders have imposed a deadline of February 9th for the project to be complete. How should we track our status regularly to get a complete understanding of how we’re doing? You might think to yourself, “Simple, we’ll measure our percentage of the complete body of work every two weeks and that’ll be our key indicator that we’re on track.” The same can be said for the budget. “If we have ‘X’ amount of money budgeted towards the effort, how complete will the product be when we run out of money?” As anyone in professional services or product development will tell you, however, it’s rarely this easy. Primarily because the data to support whatever the percentage complete value that we derived is inherently flawed, because we don’t have a basis for how fast our team can complete the work. That’s why we need to shift our thinking from what’s needed to reach the deadline, to how we measure to accurately forecast project completion. If we can be accurate in our reality, then we have data to support decisions that’ll make February 9th a reality, too.
What is it?
I use the term velocity because my teams at Rural Sourcing are almost completely Agile in our approaches to application development. For those of you that use a different methodology in your approach, just think of velocity as the amount of work that can be completed by the team in a measurable (preferably iterative) timeframe. Velocity is going to be the primary metric output to measure performance, and will be impacted by all other key performance metrics (KPIs).
Using Agile, velocity is usually measured by the number of Story Points completed per sprint. In a Waterfall approach, you may compare the number of task items completed in the Project Plan every week or assign a Level of Effort value to each item, and measure how much effort is routinely completed in the defined timeframe.
Tools and Tech
Products like Atlassian Jira, Azure DevOps, and SmartSheet are project management tools that use ticket-based workflows that are formulated around assigning levels of effort on tasks. And if you don’t want to use a licensed product, you can manage the base velocity metric simply by getting your team to add weight, level of effort, or story point values to tasks and tracking how may are completed in a set schedule.
What is it?
So, we have our base velocity number and we’re tracking. Great! The only problem is we’re not getting as much work done as the numbers indicate. What impacts can cause a lower than expected value for work completed? The first and most obvious is quality. How much rework are we doing? If our velocity isn’t taking into account the bugs, defects, or unusable product we are creating then we are going to overestimate how much our team can accomplish.
We can measure the number of bugs or defects that occur in our products or code. This number needs to be accounted for in the velocity number whether the level of effort for each bug is estimated with the same value type as the velocity and subtracted from the velocity value, or the total number of that work tracked against the velocity to determine impact.
Tools and Tech
The same tools we use to track velocity can come into play here and are very effective. Adding bug tickets or stories labeled as defects can allow you to generate reports to see what impact quality is having on your overall velocity. Tools like Plurasight Flow can really up your game. Because Flow tracks the software commits by the developers, it’s monitoring how much actual rework is done, how many errors are introduced to the code, and other areas that are impacted by the code that was created.
What is it?
This is where we’re able to increase our velocity and help determine just how fast we can go. Do we need more team members to get more work done, or is the team actually capable of doing more? This is one of the hardest metrics to gather, but has the most impact on velocity when opportunities to increase efficiency are realized. It’s difficult to identify areas that have an opportunity for improvement without trying it out via a proof of concept or trial period to see if the changes have a positive impact. We can again turn to new tech to gain valuable insights to directly identify areas to increase efficiency.
The metrics on efficiency can vary greatly depending on where the inefficiencies were found. The final outputs will be recognized via an increased velocity of the team.
Tools and Tech
Commit-tracking software like Pluralsight Flow can give you direct insights into the efficiency of your developer’s code. This allows detail for tracking this metric like never before. Here’s an example: you can see two of your developers are doing 45% refactoring of code daily in a certain area because of a previously completed effort that is negatively impacting your team’s ability to reach their target velocity (but would otherwise be unknown.) Perhaps you determine that giving the responsibility of refactoring old code to a single team member can increase your efficiency by 25+%. Can you imagine that kind of efficiency gain without a trial and error approach?
Measuring the velocity of a team and how much they can gain if they’re performing efficiently is fundamental for any forecasting, planning, and decision-making. Like the Zoom meetings and other technologies that we now rely on more than ever, we can leverage new applications to better track, manage, and report our team’s performance like never before. Three simple metrics can change how we measure performance and status in a whole new way.
About the Author
Chris Simmons is a Principal Consultant in our Augusta Development Center, and has been an evangelist for Agile methodology since its inception into mainstream IT. As a leader in the project management space for over 15 years, he’s managed and enhanced efforts for multiple Fortune 500 companies’ applications, including projects in the manufacturing, fleet management, financial services, and professional services industries. Chris lives in South Carolina with his wife and newborn son, and enjoys golf, guitar, hiking, and travel.
How to Avoid Stalling on Your Path to App ModernizationRead More
Mobile App Testing: Real or Virtual Device?Read More
Incorporate User Feedback Into Your Product Development LifecycleRead More
Intro to Quantum Computing with Amazon BraketRead More