This document tells the story of how a team of data engineers improved their performance and morale through the use of agile metrics. When the author first joined the team, they found cycle times were extremely long, averaging over 50 days per item. By discussing metrics like velocity, cycle time, and burn down rates with the team and helping them apply lean principles, the team was able to steadily improve and reduce cycle times to under 5 days on average. While numbers provided insight, the most important outcome was that conversations around the metrics helped the team work better and increased their happiness and energy at work.

1. Hello! Today I am going to tell you a story, the story of the transformation of a team
and how metrics are supporting this transformation
This story is for you, if you have ever wondered what’s the role of metrics in agile
development and team morale
1

2. This is the story of a team and it is important to remember that the numbers in this
story are the language, not the main characters!
Let's not forget what matters the most and why we are doing this!
2

3. This is a story narrated through the language of numbers, let’s introduce some
numbers!
The main characters in this story are data engineers, and the architects, product
owner, and scrum master supporting them.
With the majority of the team being data engineers, you can see how numbers are
the appropriate language to use here!
I joined this team in July, facilitating their quarterly planning event and then I went on
holiday for ten days.
3

4. When I came back from my holiday, I found my inbox full of requests from
stakeholders . They wanted to know when their items were going to be done.
Having only worked with the team for a few days, I took a look at the metrics to work
out an estimate for our stakeholders.
4

5. I looked at the team velocity and say/do ratio.
5

6. I looked at the previous 4 sprints (sprints 1, 2, 3, and 4 in this graph) and I noticed the
team was under-promising and over-delivering. Not really predictable, but at least it
wasn’t the other way around!
I joined the team during sprint 5 and, even at a glance, you can see the stabilizing
effect of applying lean and agile principles. What comes next explains how we got
there.
6

7. After looking at the velocity and the say/do ratio, I looked at the cycle time.
7

8. On average, any item in the backlog was taking 50.5 working days to complete (that’s
more than 2 months in calendar days!).
With a standard deviation of 84.7 days, an item in the backlog could take up to 135.2
working days. That’s more than 6 months in calendar days!!!
How was I going to answer the questions that our stakeholders wanted to be
answered? Erm… with 3 items in the backlog to complete your request, it is going to
take between 6 months and forever…
8

9. So I started asking questions to the team:
• What are we doing?
• Why are we doing this?
• Who is this for?
• When is this due for?
• Where do we find the relevant info?
• How do we know when this is done?
• What are our top 3 priorities as a team?
Within a week you could hear the team becoming impatient because of all these
questions I was asking and then…
9

10. Then I showed them the data and the effect of applying lean and agile techniques on
the team performance.
And you can't believe the enthusiasm!
"I want more of this!"
"A scrum master that talks our language!"
"A scrum master that is not using metrics to beat the team up!"
10

11. The ups and downs are to be expected when items in progress are moved to another
sprint
11

12. The situation has been improving and the numbers are converging towards
manageable figures. As long as on average an item can fit into a sprint (10 working
days) it doesn’t matter if the numbers are not perfect
12

13. After 6 months the team is now converging to an average cycle time and standard
deviation somewhere between less than a day and 5 days and those glitches in
standard deviation are becoming fewer and smaller.
Do the numbers matter?
No not really. What matters are the conversations that the team is having around
those numbers and is learning to work in a new way that suits them and addresses
the customers’ needs.
The maximum in this graph is 4.3 average; 1.7 standard deviation
13

14. So, what do we use metrics for? What are the questions we should answer when we
look at different metrics?
14

15. Velocity and say/do ratio: is the team busy?
15

16. Cycle time: is the team effective?
16

17. Burndown: is the team working at a sustainable pace?
17

18. I am going to ask you what metrics you are going to use after today with your team,
and…
18

19. And the most important questions of all: are the people involved happy? Is the team
happy? Are the customers happy?
Because numbers can provide answers to a lot of questions, but at the end of the day
the only metrics that matter to me are the smiles, the energy, and the feeling that the
people involved in the process of making our amazing products are happy.
While I was talking numbers with my team of data engineers and speaking their
language, what I was secretly tracking was the difference that lean and agile practices
were making to their life.
19

20. This is what matters!
20

21. Thanks!
21