The Agile methodology brings numerous benefits to Software Development. Specifically, agile metrics for software development must be carefully selected to bring the most out of any software project.

As the Agile Manifesto states, “Working software is the primary measure of progress.” However, a working software only tells half the story. Usually, all the work performed behind the scenes includes piles of documentation, hours of meetings, countless messages in Slack, multiple Trello board updates, and so much more. This data is what creates magic and insights for software development team leaders and project managers.

This data needs to be accounted for and measured to gain real, powerful insights about performance and productivity. Next, the Business Development Vice President at Svitla Systems, Andrey Okhrimets, shares his experience on how to measure productivity and what data is worth collecting for development teams to ensure growth.

When effectively applied, productivity metrics in software development provide some of these advantages:

• Precise planning: Project managers and team leads are able to detect, prioritize and maintain a record of issues in a more accurate way. It increases overall team productivity and helps predict outcomes more precisely.
• Predictable project management: Software development metrics serve as indicators of what needs an immediate fix, optimization or monitoring. It simplifies the workflow and motivates the team to search for suitable solutions.
• Strong client relationships: Effective measures foster transparent relationships with clients, ensuring all requirements are met within the predefined time frames and budget limit.
• Discovery: Metrics help software development teams keep work progress under control, but it also helps discover new insights that can transform the direction, focus, and success of the software project.

Agile Metrics to Measure Productivity

Actual Stories Completed versus Committed Stories

This metric shows the team’s ability to understand and predict its capabilities. It compares the number of committed stories during sprint planning to the stories marked as complete during the sprint review.

In essence, this metric gathers and analyzes data that helps understand where the team’s capacity falls short or if there’s a bottleneck preventing progress. While it is not an innovative metric, it is a productivity measurement technique that makes the lives of the software development team a lot easier.

Ultimately, clients put a high value on reliability. If the software development team agrees to complete a project by a specified date, the client holds this true and expects a time-appropriate delivery.

Deviation from estimation

This metric measures the gap between the project estimation and the actual time spent on a project. It compares the time allocated for a task and the time that was actually spent on the task.

Quality, on-time delivery determines the success of a software development project. The measurement of the deviation from estimation helps development teams deliver the best results by holding members accountable for their estimations.

Client satisfaction

This metric reveals if the software development team meets the client’s expectation via a feedback system.

To deliver a quality product, there are many software development metric examples to consider: market share, ROI, defect rate, and more. But one of the most prominent metrics to deliver valuable insights in terms of product quality is the client satisfaction metric.

Software development teams receive direct and indirect feedback from clients or stakeholders.

The tips

The Product Owner (PO) needs to invite the right people. All teams belonging to a tribe or department, working on the same product or value area should be present. Invite internal and external customers who are in some way involved in the product development process. Note there is no use to start inviting real customers randomly, since not having any context will lead to hindering your SR with questions that should be addressed in other sessions.

Make sure you announce which features you will be inspecting in an invitation (e-mail or slack or whatever you use) so your stakeholders can decide if these features are important enough for them to join the Sprint Review. Most importantly, don’t forget to invite “the one who pays the bills”, being the CEO or some other company hot-shot. Knowing that the CEO will participate improves Sprint Review quality because it puts healthy pressure to perform on your teams. Note that for your very first Sprint Review Bazaar, don’t push too hard on getting those stakeholders in. Your second Sprint Review Bazaar will be better. See it as a dressed rehearsal. When successful, the word will spread, you will get traction.

Don’t focus your Review on teams doing their dance, but shape your Sprint Review using the delivered features. This might require members from different teams to collaborate on inspecting a single feature. Inspecting means that a couple of team members do a workshop or hands-on demo for a feature they helped to deliver, observe the visitors and engage in a dialogue.

The main concept of the Sprint Review Bazaar is that you run multiple inspections in parallel. For each delivered feature, create one “shop” in your bazaar. Attendees of the Sprint Review need to choose which shop they want to visit. People can visit two shops per Sprint Review.

Preferably, have the SR in the regular working place. The time box available in the sprint to do the development work is over, so nobody is doing anything else anyway. A separate dedicated location is fine too, but not necessary. Ensure your “shops” are not too close to each other so that the people do not disturb other shops working close by. Let the “shop members” create a big banner with the feature name on it for people to know what they can learn in each shop.

If you have people cooperating in the SR from a remote location, then use a closed room (a meeting room) that is sufficiently equipped with remote meeting gear for the remote team to interact. A local facilitator is required to help to make the remote contribution successful.

To prepare and verify the quality of the SR, I always plan for preparation sessions with the PO and the teams to focus on the content of their presentations. The Scrum Master and PO play an important role in asking the right questions to get the performances at the desired quality level.

Plan for the regular time-box as prescribed by Scrum. Don’t be tempted to make it any longer. Strong facilitation of the Scrum Master required!

Arrange for a whiteboard, a projector or large screen, snacks, and drinks and create an informal atmosphere.

Conclusion

Having a set of comprehensive measure metrics and indicators in software engineering is a necessity. As the saying goes, knowledge is power and analyzing valuable metrics helps identify, correct, and improve activities in software development to achieve effective progress.

While metrics alone won’t necessarily guarantee success, they provide the right tools to know when to initiate discussions, develop action plans, conduct evaluations, and share feedback.

Let us know in the comment section how your team measures activities and tracks progress.