Agile Teams, Velocity is Slowing You Down

Most people’s introduction to an Agile framework is Scrum.

Scrum is a framework that helps teams break down work into sprints. Scrum works as a vehicle to get teams organized and working on a regular cadence using empiricism to improve their processes, and it increases transparency into delivery for leaders. But the return on investment (ROI) for data organizations after implementing Scrum is usually a lot less than they were expecting. Time to market doesn’t decrease as much as they’d hoped. Why does this happen?

‍

Scrum is simply not optimized for data delivery. There are lots of best practices Scrum Masters use that are awesome for software development like vertical slicing, but those practices are not as important for delivering data products. Two practices that will detract from your data delivery are estimation and velocity, which tend to go hand in hand. Since 36% of teams say their productivity is measured in terms of their velocity, it’s a pretty important metric. (Only 29% are judged by value delivered to the business and 25% by sprint or burndown rate).

‍

What you'll learn in this blog

• How estimation and velocity work in Agile, and why they can create challenges for data delivery.
• The subjective nature of estimation and why it’s not an effective metric for comparing team performance.
• Why velocity as a productivity measure may hinder data delivery rather than help.
• Practical tips on improving data delivery processes by focusing on smaller, independently deliverable units of work.

‍

What are estimation and velocity in Agile?

Estimation is the activity of pointing, or assigning a point value to, different stories (not the kind you read in storybooks—we mean a unit of work for engineers to execute) in the backlog to understand the relative level of effort of each unit of work. Fun fact: “Stories” came to be used in Agile because one template for tickets is called an “end user story” and is used colloquially even if a ticket is not using that format). There are a couple of key points here that I’d like to call out:

• Estimation is subjective
• The sizes of stories are relative to each other only within a team

What I mean by this is that an individual team may point a story as a five for reasons completely their own: the experience level of the teammates, the maturity of the team as a whole, and so on, that are not comparable between teams. Another team may point that same story as a three or an eight and, within the guidelines of relative estimation, that’s completely valid.
 
So why does this cause issues?

‍
Data and development rely on different processes

Firstly, data projects don’t always have the same DevOps process as software development. In data projects, it’s common to have end users validate the data rather than go through a QA process.
 
Second, people often separate development of the data model from the dashboard.What this means is that the estimation exercise is not taking into account everything necessary to deliver a piece of business value, so the points you deliver at the end of a sprint don’t mean anything. They can be points that signify unrealized business value and are essentially irrelevant to business objectives. Put simply, a user cannot use the data model without a front end, and the front end is the element that ultimately delivers measurable business value. There are ways to write your stories so that they include all the functionality needed to deliver a piece of business value (we call writing a story this way “vertical slicing”) but it doesn’t genuinely reflect how Data Engineers do their work.

‍
How leaders use estimation and velocity to measure performance

The secondary issue with estimation and velocity is how leadership uses them. As was mentioned before, estimation is subjective and relative. Despite that, leaders are often tempted to compare velocity between teams as a performance metric. The intention of velocity is to be a team metric to alert leaders when their burndown doesn’t look like expected. It can be used to ask questions like Did the team have changes to capacity? Was there a holiday or outages? Why wasn’t x considered during planning to adjust how many points the team took on for the sprint? That’s the whole of what velocity should be used for, but being unable to compare performance between teams can be frustrating to leaders who want to project a timeline for a program based on burndown of multiple teams.
 
So, what do we recommend?

‍
Throw the concept of velocity out the window.

It’s only slowing you down. We are not suggesting that you throw the concept of metrics out the window, however. Instead, data organizations should be looking to Kanban for inspiration. Instead of subjectively sizing stories relative to each other, Kanban assumes that after a six-week period, the size of the stories averages out. The reason this works is that each story can make it through the development cycle without being attached to the others. (Here’s an example of how this works.) You may have a sprint of ten small stories and another sprint of three large stories, but over time the amount of small, medium, and large stories is going to even out. One story is simply one unit of work, as long as you “right size” the story to deliver the smallest valuable piece of work possible and don’t try to fit an entire dashboard into one ticket.
 
If every story is the same and the points don’t matter to my metrics, how do you know how you’re performing?
Cycle time. From the time an engineer on the team picks up a ticket, how many working days does it take for that ticket to hit production? That’s your cycle time. What’s lovely about it is that it is not subjective or relative. You can compare it between teammates, average it for the team, compare it between teams, and compare it between business verticals.
 
There are mitigating factors you’ll want to consider of course, such asthe difference in experience between teammates. Newer teammates may get fewer tickets completed because they’re learning, and very experienced teammates may get less tickets done because they’re doing architecture design or coaching others. Both ends of the spectrum are valuable contributors to the team and assisting with delivery; there’s no single metric that can tell the whole story, but at DI Squared, we believe cycle time paints a clearer picture than velocity. 

‍
How DI Squared can help you improve delivery through Agile

Our teams use techniques like Kanban to manage workload in our partnerships with clients, but we also offer individualized services that may help your internal teams to independently implement more efficient work management strategies. Our clients have seen 40% increases in productivity within a month of coaching and/or workshops.
 
Book a complementary 1:1 with our Agile director to gain more insight into how to strengthen program management.

‍