How engineering leaders control product delivery of remote teams

At first glance, there is no difference in working remotely compare to normal day in the office. But the truth is that remote work requires a lot more attention of engineering leaders. While most of the teams switched to a new way of working quite fast others are still fighting infrastructure and communication challenges. Below I'll give you 3 metrics to stay in sync with your team and control delivery.

Sprint completion rate

To calculate sprint completion rate you need to get the number of completed tasks in the sprint and divide it by the total number of tasks for the sprint.

Sprint completion rate = delivered tasks/total tasks for the sprint.

This number should be in the range from 80 to 100 percents. This is a very simple metric which provides visibility for tech and product people. It's quite hard to argue on this number because in the most cases sprint backlog is an agreed list of tasks both by engineering and business.

Team velocity

There are 2 kinds of people. Who likes burn-up or burn-down charts. Story points as a measurement of the complexity of the task are widely used for measuring delivery by the team. We are not comparing an actual number of delivered story points, but we rather observing the trend. If Team A decreases the number of delivered story points 3 sprints in a row, it's time to stop and arrange a retrospective :) In fact, it can be a sign of many issues.

Time to market

Time to market(TTM) is the best metric in my opinion. This is the metric which is easily understandable by anyone. But to make it clear TTM - is a time which a task takes to reach a customer. In software development world TTM means the time from when we move tasks from backlog to in progress till release to the customer. I like this metric because it's hard to cheat.

To improve this metric team can start splitting tasks to smaller subtasks. But this is great - small tasks improve estimation and prevents huge problems on the project.

To improve this metric the team can start making frequent releases. But this is great again because this is a direct way to continuous delivery.

How to calculate time to market

There is one problem with time to market - how to calculate it. Well, this is what we've done in Valycs to simplify this task. Here 2 simple steps you need to do:

  1. Provide API endpoint which returns currently deployed commit to production\

  2. Connect the endpoint in valycs.

    The format of release history endpoint is very simple. It's an GET REST endpoint which returns JSON document, in the same way, health check or status endpoints works.

    To connect the endpoint go to Integrations and paste the rule as on the image below.Release_history_page

With your endpoint in place we provide you with 4 graphs:

  • Time to market based on story points

  • Deployment frequency

  • Deployment delays

  • Time to market trend

Time to market based on story points

This graph is useful for predicting the delivery time based on historical data. As you can see it's possible to predict the delivery date with a specific probability. Also measuring the difference between 50th and 75th percentiles you can understand your team's estimation skill. The big difference between percentiles indicates estimation issues.



Time to market is an essential metric to understand your team's delivery. If you want to know more about software metrics and how to analyze your team's work - schedule a demo.


Subscribe via email

Receive email with a new post as soon as it's published