Sprint Progress - Why and How to Track It?

“Working Backwards” is a great strategy to figure out what needs to be built however when it comes to software development often what helps is continuously tracking your progress towards your goals. Thus we came up with this strategy for development teams called “Working backwards, Tracking onwards”. The idea is to continuously track what is your team’s sprint progress on the plan that you have made, so you can proactively course-correct when needed. Rather than figuring it out in a quarter retrospective after months.

Why should it matter?

Simply put, tracking sprint progress and looking at your sprint reports is important to course correct, and think of this as an OODA loop (Observe, Orient, Decide, and Act) where your scrum teams are often doing the decide and act, without observing and orienting themselves with the reality. And tracking your progress gives you the ability to connect with the reality of what’s going on and helps you make better decisions.

The entire purpose of sprints revolves around faster feedback to course correct in case something is not going on as expected. And tracking sprint progress helps in achieving that.

How to track Sprint Progress?

To answer how, first, we need to be absolutely clear on the intentions of tracking progress, and what it will help in achieving.

This is what a Sprint is defined as:

Sprints are fixed-length periods of work that ensure short iterations for feedback in order to inspect and adapt both how work is done and what is being worked on.
- Scrum.org

Breaking this down into what is the data I should look at and what is the action I should take looking at the data, brings clarity into this process.

How work is done and What is being worked upon (Data)

The how and what helps us get the right data in order to analyze what needs to change. Any analysis is as good as the data under it, thus it's absolutely important we figure out the right ways to look at our sprint progress.

Inspect and Adapt (Action)

The focus always has to be on understanding what is going on and what needs to change to help the team achieve its sprint goal. There’s a lot of stress on “adapt” here because that's the fundamental principle of being agile, that a team is able to quickly change to deliver the most value for customers.

Continuing on how and what work is getting done, we will be looking at some sprint metrics that highly-effective scrum teams measure.

How work is done?

Sprint metrics to look at how work is getting done in a sprint.

1. Predictability

In simple words, this is an understanding of how much the team can predict its own work outcomes. If your team can complete 16 of the 20 tasks you committed at the start of the sprint your predictability is 80% and a number above 75% is usually considered in the good range, having predictability above 90% is phenomenal. Count of spilled-over tasks is another good way to track your predictability. Looking at your past trends across sprints on how predictable a team is, can help you understand the red flags. Often the first step to better predictability is a very organized and to-the-point “sprint planning” meeting.

2. Additions and removals after a sprint has started

Also known as “scope creep” in agile terminologies. The best way to track this is by looking at how many tasks or user stories were brought in or removed because of some ad-hoc change in requirements or re-prioritization. Higher scope creep means the dev team is often not prioritizing well or is undergoing requirements change too frequently.

The problem with scope creep is also that it would lead to a lot of wasted effort. If a developer has already started analyzing and working on a task that suddenly gets de-prioritized, the efforts spent here would not lead to any outcome at the end of the sprint. Also, dissatisfaction with not completing tasks and the overload of context-switching are added problems the team will start facing due to frequent scope changes.

3. Work Breakdown Structure (WBS) and Burndown

The heart of project management is that a bigger chunk of work is broken down into smaller and more manageable pieces, which helps in better organizing the team and brings clarity on what needs to be done. If looking at a task a development team says “Looks like something we can complete in a week” without breaking it down into smaller tasks, it’s a blanket statement to hide the fact that they don’t know yet what changes need to be done in delivering this task. The best way to track WBS is by seeing at the start of the sprint how well your tasks and stories are defined and the detailing of sub-tasks that are created under it.

Burndown represents how well a team is nearing the goal that they had planned at the start of the sprint. The Burndown chart primarily consists of two data points, ideal state - where the team should be in terms of remaining efforts (based on how much the team started with and the number of working days in a sprint), and actual state - actual efforts remaining. And there’s immense value in looking at this data, as it helps in comparing where you are and where you should be and it also says a lot about whether the team would be able to achieve the end goal or not (which is a positive outcome every team should care about). Burndown charts also act as a precautionary indicator that the team won’t be able to reach their goal before it actually happens.

Two parameters to measure the burndown chart would be.

1. How consistent is the burndown across the days of the sprint?
2. How close are the actual remaining efforts to the ideal remaining efforts?

What is being worked upon?

What is being worked upon is always either equally or more important than how it is being worked upon, as it wouldn't matter how much your team is able to complete, if the tasks that were completed don’t contribute to customer value.

1. Planned vs Ad-hoc tasks

In the financial world, there’s a beautiful concept of “run the bank vs change the bank”. Similarly, in development efforts, it's absolutely crucial to understand how much effort was spent in keeping the lights on (aka support tickets, bugs, and other periodic maintenance activities) vs in developing new features (your bigger initiatives or epics generally spanning across sprints, sometimes even quarters). This helps you actively track and keep your operational overhead in check.

Looking at the percentage of completed tasks that were dedicated to bigger initiatives or epics is a good way to measure this. If a team’s support overhead is greater than 25-30% in sprints, that's a cause for concern.

A good way to understand where you are spending most effort is by looking at it by JIRA task type, looking at how much effort you are putting into different types of would give you a good insight into your team's effort investment portfolio.

2. Work In Progress (WIP) tickets

What tasks or stories are being worked on by which developer and knowing the updates on each, helps you best visualize what is going on in the day-to-day of a development team. And helps you in understanding what could be a blocker or a critical task that needs to be completed with the highest priority.

The count of WIP tickets across developers helps you in figuring out how much context switching is happening across the team. A higher number of WIP tickets indicate high context switching and a lack of clarity over priorities within the team. A good number to strive for is by keeping WIP tickets always lesser than three per developer in a sprint.

3. Blocked In Progress tickets

Looking at “What is being worked upon?” includes looking at what should be worked upon, but is not. The best way to understand this is by looking at tasks or stories that are In progress and have had no activity in the last 2 working days. Activities should include any activity on that ticket, commits, pull requests, comments, and deployments related to that task. And inactivity for a few days would indicate that the developer might be blocked on the task at hand and it would be best to have a conversation and know if the blockers can be resolved in any way.

These blocked tickets also become ideal candidates to be talked about in your daily standups, as one of their key purposes is to resolve blockers. And even if some team member is not able to say out loud they are blocked on a task, you will be able to proactively detect this and take necessary action.

Inspect and Adapt

The intent with which we look at data, and the action we drive from it is the actual value that we will be deriving from tracking the progress of sprints. “Knowledge is only potential power but action is power”.

And the most important intent with which we should look at the progress of the sprint is to adapt. To make changes if necessary to reach our sprint goal.

A few tips to course-correct within your sprints.

1. Ask the team “how much they think we will be able to complete from the planned items at the start of the sprint” - this will help in keeping the focus toward the end goal. And often in answering the standard three standup questions for one’s self in daily scrum meetings (What was completed? What is to be done? What are the blockers?) developers lose sight of the team goal, which helps in keeping the focus on the thing that matters.
2. If you want to improve your predictability or have a better work breakdown structure or smoother burndowns, it's very important to engage the team in these improvements. Gamifying this by creating leaderboards across scrum teams and even within developers helps in keeping the team engaged and creates a healthy competitive environment within the team. Example: creating a monthly leaderboard across scrum teams on the percentage of planned items completed or on how close the burndown chart is to the ideal line is a great way for teams to focus on these important metrics.
3. A great way to take action would be by setting incremental goals on key metrics after understanding the benchmarks and having a way for the team to be notified about them. Example: You can set a goal of not more than 3 WIP tickets per developer in a sprint, and be notified whenever this limit gets breached for any team member.

Benchmarks

We are surrounded by data but starved for insights.
- Jay Baer

To make the sprint metrics we talked about actionable and insightful it's important we understand what elite and high-performing teams do so we can keep our goals in accordance with that and take the necessary action to continuously improve.

A few benchmarks that high-performing dev teams follow:

1. Parallel sprints - Don’t have more than one active sprint within a scrum team. As it creates complete chaos within the team with no clarity on what is important and what needs to be completed. Also, all the scrum ceremonies like daily standups, goal setting, and retrospectives go for a toss when the same team is working across sprints.

2. Task completion percent - Having more than 75% completion to committed ratio is a good number that you should aim for. One thing to note here is we are specifically considering only the committed tickets, For example, if you are committing to 5 tasks at the start of a sprint, and then 2 new ones get added in the middle of the sprint, we should still consider only 5 as the originally committed tasks. This helps in having better predictability within what will be completed for a development team.

3. Median cycle time of bugs - Should be lesser than 2 days. This considers the time it takes for you to resolve bugs, that is from the time the team has started working on it till it gets completed. This doesn't account for the initial prioritization time, example: if a bug is discovered today but the team scopes it in a sprint after 3 weeks and completes it within 7 hours, the cycle time will still be 7 hours.

4. Sprint duration -  A time period of 2 - 3 weeks is the most common and feasible sprint duration, it helps the team in getting iterative and early feedback on what they are building. Anything over a month is definitely a red flag.

5. WIP tickets - The average of daily in-progress tasks across a development team should be lesser than 3. Research shows even with three parallel tasks, a developer loses close to 40% of productivity to context switching.

6. Adhoc tasks - Consistently having lesser than 30% of effort towards ad-hoc tasks is a healthy sign for a development team.

Measuring and tracking sprint progress is absolutely crucial for the success of the development team. We looked at what sprint metrics should a team look at and what action should they drive after looking at these metrics. And most importantly, we looked at benchmarks high-performing engineering teams follow to ensure their sprint processes are healthy.

If you are looking to measure your sprint progress effectively on the ideologies mentioned above, AnalyticsVerse could be a great fit for your development team. Try it out here.