A holistic approach that accelerates your current vision while also making you future-proof. We help you face the future fluidically.

Digital Engineering

Value-driven and technology savvy. We future-proof your business.

Intelligent Enterprise

Helping you master your critical business applications, empowering your business to thrive.

Experience and Design

Harness the power of design to drive a whole new level of success.

Events and Webinars

Our Event Series



Featured Event
24 - 25 Apr
Virtual event: 7 live sessions
Our Latest Talk
By Kanchan Ray, Dr. Sudipta Seal
video icon 60 mins
Discover more about us,
an outstanding digital
solutions developer and a
great place to work in.
Financial information,
governance, reports,
announcements, and
investor events.
News &
press releases
Catch up to what we are
doing, and what people
are talking about.
Caring &
We care for our world.
Learn about our ESG


Beyond Agility, the convergence of technology and human ingenuity.
talk to us
Welcome to digital product engineering
Thanks for your interest. How can we help?
Martin Dragosits
Martin Dragosits

In the first part, we discussed the basics of agile metrics - story points, velocity, and release planning. Part two deals with the possible ways to determine the progress during a sprint and shows the advantages and disadvantages of the different measurement methods.

Progress in a sprint – An overview

During a sprint, progress can be measured in three ways:

  1. Number of tasks to complete/completed tasks
  2. Sum of story points to achieve/story points achieved
  3. Estimated open efforts

The representation takes place as a Sprint Burndown chart. The form of representation is the same for all variants. The X-axis shows the time course for each day in the sprint. The Y-axis represents how much is still open in the sprint backlog.

All we need is a flipchart, which we update daily. The Scrum Burndown chart helps the scrum master to track sprint performance in real-time, and also check the agility of the team.

An experienced team takes a critical look at its scrum board and evaluates whether the sprint target can still be reached. But for many, it is helpful to get this information, supported with a graphical representation. For a scrum master, it is, of course, also of interest to collect data that can help to learn more about the team's way of working.


1. Number of tasks to complete/completed tasks

Planned tasks should neither be too large nor too small. A suitable size is if they can be completed within a day. Measuring sprint progress based on scheduled and completed tasks is a simple approach that still gives you a lot of information.

Open tasks in a sprintExample: Open tasks in a sprint


  • We get a continuous curve of the completed activities.
  • The representation of tasks is more meaningful than that of story points - we recognize when the team was more agile and when not as much. Was the start-up phase long? Did the progress stagnate suddenly? Is there a recurring pattern at the end of the week?
  • It is easy to assess whether the sprint target is still achievable.
  • The information is easy to determine. By counting how many tasks are hanging on the scrum board as "not done yet,” we can set a corresponding point on the flipchart and draw the line further.


  • Tasks are not always equally comparable; nevertheless, the tendency of the team is well recognizable.

When to apply?

  • If we want to analyze the course of the sprint in detail.
  • If we want to know more about whether the tasks have a senseful size. Are they defined too inaccurate or too detailed?
  • If the team takes too long to implement the first stories.
  • When, after a good start, things don't go well (less productive phases).
  • When the goal is to achieve a continuous flow of completed tasks.


2. Sum of story points to achieve/story points achieved

The measurement criteria are the story points planned in the sprint. 

  • We get a curve of the completed stories.
  • We do not need a second measure of the progress.
  • The values are easy to determine. We add the story points of the user stories not finished on the scrum board, set a corresponding point on the flipchart, and draw the line further.


  • The measurement method is coarser than the number of tasks still open or the remaining effort.
  • It is less meaningful during a sprint because it can take tests or test automation to complete a story, and it is less transparent than the other two methods whether there are idle times in the team phase of a story.
  • Tip: You can use a cumulative chart that shows the progress of status transitions; of course, this is also more time-consuming.
  • Compared to the other two methods, it is less easy to assess whether the sprint target can still be reached.

When to apply?

  • If we want to focus on completing stories (stop starting, start finishing).
  • When we need to work on stories one after the other (continuous flow of finished stories and not work on many at the same time).


3. Estimated open efforts

We estimate the open effort in person days or hours and continuously adjust our estimates.


  • We receive a detailed curve with the information on how much effort is still open.
  • Fluctuations and changes during a sprint are visible.
  • It is easy to estimate whether the sprint target is still achievable.


  • Determining the values is time-consuming.
  • We get an apparent accuracy that is as meaningful as conventional estimates.
  • Can the team estimate the efforts accurately enough? Does the effort pay off concerning the benefits of the approach? Is the team still working together to achieve the sprint goal, or is everyone just trying to keep to their estimate?

When to apply?

  • If we do not reach sprint targets, we improve the assessment of the sprint target and the activities necessary to achieve it.


It also depends on the team and the environment which of the variants you choose. According to the principle "Keep It Simple and Stupid," I prefer option 1, counting and displaying the still open tasks; this is partly also a matter of taste.

Share your experiences of how you have chosen the right agile metrics for your teams with the author at

To understand how to build agile teams, read our blog on Top 10 factors to build high-performing agile teams.


Agile , Scrum , Metriken

Martin Dragosits
Martin Dragosits

Agile , Scrum , Metriken