Team metrics are a set of metrics that help the product team track progress and subsequently adjust the product development strategy. Use them to measure team growth and make sure that product increments are delivered on time with the highest possible quality.
Table of contents
Team metrics for measuring team performance
There are a number of team metrics for measuring the effectiveness of each sprint. Here are the essential measures:
Sprint goal
A sprint goal should be a short, yet encompassing statement that clearly defines the objective of a sprint. This metric informs what should be completed during the sprint, but can also be a source of motivation for the team. The product owner, the scrum master and the team should all be focused on the goal and strive towards achieving it.
The sprint goal allows the team to swiftly test assumptions during scrum meetings, so the next sprint goal can be improved, and the team can quickly adapt to changing circumstances.
A well-defined sprint goal keeps everyone on track to achieving it, and can be used to monitor the progress of work during the sprint. It also helps to maintain the reason for building the product increment, as the team should create a product that may potentially be released.
There are a few templates that can be used to define a sprint goal., The most common ones are a template from Scrum.org:
- Our focus is on <Outcome>
- We believe it delivers <Impact> to <Customer>
- This will be confirmed when <Event happens>
and a template from Roman Pichler:
- an actual goal
- metrics to determine if the goal has been achieved
- a method employed to reach the goal
The sprint goal is one of the most important team metrics used in Scrum. It helps to maintain focus on tasks related to that goal. When the goal is well defined it is easier to achieve a desirable outcome, compared to not having it defined at all or having it defined poorly.
Team velocity
Velocity is defined as the average amount of work that can be done by a team in a sprint. Team velocity should be used as a planning tool for the Scrum team, as it helps to predict what amount of work can be completed in a sprint based on the history of previous sprints. If a team delivered 40 story points two sprints in a row, it is quite possible that during the third sprint they will also deliver 40 points of work. The longer the history of each team, the easier it is to predict the amount of work they will deliver in the following sprint.
Velocity is a great team metric as it allows planning of future workload, but it can also be quite dangerous if used incorrectly.
You should never use a team velocity metric to:
- measure only a part of the workload - in this situation the velocity metric won’t ever be an accurate reflection of team’s real velocity;
- measure team efficiency - instead of striving for the highest possible velocity, one should aim for a stable velocity; using it to achieve the highest numbers will only drive up false performance, as the amount of work done probably won’t go hand in hand with its quality;
- compare teams - each team has a unique velocity and their effectiveness shouldn’t be judged on the velocity alone.
It is important to remember that velocity can’t be judged as good or bad, as each team has their own tempo of work. Velocity measures help the product owner grasp how quickly the work will be finished and to better understand the progress.
Project deliverables
Project deliverables may also be known as “products” or “outputs” and they are the tangible or intangible goods or services that are necessary to achieve the project’s objectives.
There are three types of deliverables:
- external deliverables - the deliverables that are presented to the clients and stakeholders; usually the most important ones and they are the ones that should be particularly well taken care of;
- internal deliverables - ones that are not important to the client or the stakeholders, but are required to run the project smoothly;
- planning deliverables - including documentation such as budget, project schedule, or the project scope.
Project deliverables shouldn’t be confused with project milestones, as contrary to deliverables, project milestones do not require anything tangible to be delivered by the team. A milestone is more of a checkpoint and marks a new phase of the project.
The qualities of a good project deliverable:
- it must be tangible
- it should signal a completion of a project phase
- it should be of value to the client and/or stakeholders
Project deliverables are crucial to the stakeholders as they can clearly see the progress of the project and be sure that all necessary tasks have been completed.
Timeboxing
Timeboxing is a team metric that allows one to allocate a specific timebox for completing a certain task. Dedicating or ‘blocking out’ boxes of time in your calendar, as you would do when scheduling meetings, will help you maintain focus on a task and therefore improve your work quality. Timeboxing helps to assess the required time to complete tasks and appropriately adjust the timebox next time.
A timebox can be as short or long as you wish, varying from, for example, 30 minutes to even weeks (depending on the work that needs to be done). A popular variation of timeboxing is the pomodoro technique that divides work into 30-minute cycles with 25 minutes of work and 5 minutes of rest (and with a break after 3-4 cycles).
Timeboxing was used in the Agile approach from the beginning but was developed even earlier; timeboxing was being discussed as far as over 30 years ago! This team performance metric has really stood the test of time as it is continuously used nowadays to make tasks easier to achieve and improves the quality of work done.
Bug metrics
Why is measuring bugs important? Because it verifies whether the team delivers a high quality product. It is crucial to remember to set a benchmark to measure bugs against; If we find out that there are 480 bugs while we estimated we would find 238, it is clear that there is room for improvement.
What exactly can we measure? There are many bug metrics to choose from, so you need to consider your needs wisely and choose the metrics that will suit your product best.
Here are some examples:
- total number of bugs in the product
- number of closed bugs in the product
- number of open bugs
- the time it took from finding a bug to closing it
- the time it took to fix a bug
- bugs related to data
- bugs related to specification
- bugs found in component testing
- bugs found during review of the requirements
The team can learn a lot from the bug metrics and tracking improvements will better capture the progress made.
Work in progress (WIP)
This agile team metric shows the number of work items started but not finished. Having too many WIP items at a time is detrimental to a team’s performance as a person can only truly focus on one thing at once. Multitasking doesn’t really mean doing many things simultaneously - it’s rather an ability to quickly switch focus between tasks, and it’s extremely difficult. That’s why it’s always better to limit the number of items in progress.
If the team notices that they have too many things started but not many finished it is a sign to reassess the priority of each task and decide on the next steps.
Burndown chart
A burndown chart shows the amount of work done in a sprint and the work that remains. A burndown chart grants clarity on what is yet to be done, and shows whether the work is on track or off track. It helps to track progress in relation to the ideal situation and prevents wishful thinking.
Tracking the burndown chart makes releases more predictable, so the product owner has the assurance that the product will be delivered on time. This metric can be created by a scrum master and updated during a sprint.
It is a great practice to try to go as close as possible to the ideal situation. If the team misses deadlines it might be a sign that the team is committing to a workload greater than they can handle. On the other hand, finishing too quickly isn’t good either. It may signify that a team may not be committing to enough work.
A burndown chart should resemble a mild slope, not a drastic drop or a drastic rise.
Team metrics - the final word
Team metrics are the key to truly understanding the product creation process, and they also make it easier to manage the workflow of the team. With sprint goals, burndown charts, timeboxing and other metrics you can make your life easier and some form of measurement should definitely be used to track progress of product development.
All these team metrics help increase the predictability of each sprint and the whole design and digital product development company.
Share this article:
