Velocity vs. Value
Velocity vs. Value
Is Velocity a useful tactic for teams to assess their performance and gauge capacity to complete future work? This article seeks to contextualise velocity within the broader perspective of value delivery and offer alternative metrics and methodologies to determine success.
Introduction
In many organisations, a significant amount of time and effort is dedicated to discussing, measuring, and strategising ways to increase velocity. This creates a KPI that team members must pursue every sprint, while dangerously gravitating towards ranking teams and individuals based solely on an abstract metric.
This approach often fosters a culture of discontented teams, leading to burnout and a fundamental loss of focus from the true purpose of using story points. It prompts crucial questions such as:
Why was velocity this sprint lower than last sprint?
Why has velocity stopped increasing?
Why does team A have a lower velocity than team B’s?
The race of ever-higher velocity not only deviates from the principles of software craftsmanship, but also undermines the delivery of tangible value over volume.
Before we delve further, let’s review the concept of velocity.
Velocity is determined by calculating the average number of story points completed by a team within a single sprint.
Story points consider factors such as the complexity, volume, and level of risk or uncertainty associated with a particular task. They are designed as a simplified means of expressing the effort required to accomplish a specific piece of work.
Importantly, these measures are relative to individuals, teams, and environments.
Velocity can indeed serve as a useful tactic for teams to assess their past performance and gauge their projected capacity to complete future work. However, it is essential to contextualize velocity within the broader perspective of value delivery.
At Alumni, we advocate for five key principles that organisations should be aware of and implement, to effectively measure their Agile transformation.
1. Output (Story Points) < Outcome (value metrics)
It is crucial to shift the perception that a higher number of story points automatically equates to greater value delivered or a better product.
Measuring velocity may be relatively straightforward, but its significance lies in the outcome it represents. The desire to accumulate story points should not compromise the quality of delivery. Allocating time to plan a user story, develop and unit test it, is a critical part of Definition of Done (DoD).
I could spend several days writing a paper which garners 100 views, while another paper I’ve written in just an hour receives over 10,000 views. The relationship between effort and value is non-linear. Spending more time on a task does not yield benefits if the target audience does not find it valuable. (Yes, this would be painfully ironic if no one reads this article)
True measures of a product's value lie in success metrics such as product adoption rates, customer satisfaction measured NPS scoring, or improved conversion rates. Committed work should directly align with one or more of these business goals, commonly structured as Objectives and Key Results (OKRs).
Moving the needle on an OKR, regardless of whether it involves 2 or 21 story points, should be the basis for measuring and celebrating true impact and value.
2. Learn more about your end-customer with a test-and-learn approach
By utilising experiments and trial-and-error, you can gather feedback and uncover what truly matters to your customers. Even a small piece of work that yields new customer insights holds significant value.
It is crucial for organisations to avoid overvaluing the delivery of large work volumes that address untested hypotheses or unverified customer needs. Fast MVP feedback loops allow you to focus – and re-focus on the most valuable aspects.
Mature Agile teams consistently allocate dedicated time and capacity for experimentation and innovation. They employ strategies such as time-boxed spikes, direct end-user testing, or A/B feature tests to iteratively refine their understanding of customer preferences and drive meaningful improvements.
3. Efficient delivery of value is maximised by shorter cycle times, rather than larger and more complex tasks
Fundamentally, teams should continually strive to reduce the size of their work items and limit work in progress to enable work to flow smoothly and swiftly. Given the Fibonacci scale used in story point sizing often assigns exponentially larger scores to time-intensive and complex tasks, high story point scores could be masking laborious, manual and painful work processes.
Analysing the flow or throughput rate of teams can identify blockers and periods of difficulty as code moves through the development, testing, and release cycle. This is reflected in the theme found in SAFe 6.0 - "accelerating value flow” - which stresses the importance of measuring and enhancing flow at all levels of the portfolio.
Your Senior Developer spends the majority of their time in meetings and only reviews a lengthy list of code on the last day of the sprint to accumulate those 18 points. Testing is conducted by a separate team, introducing inefficiencies and delays before work is considered ‘done’. If that sounds relatable, this is an opportunity to investigate your Sharing the review responsibilities, breaking down work into smaller batches, or re-evaluating individual sprint capacity percentages can ultimately deliver value more efficiently.
4. Sprint Cadence itself encourages continuous delivery improvements, rendering velocity as an unneccesary primary measure
Through effective sprint planning, reviews, and retrospectives, teams consciously and relentlessly focus on delivering better results with each iteration.
This principle of Kaizen, or continuous improvement, lies at the heart of the sprint rhythm, where predictability becomes a more valuable metric.
Predictability measures the percentage of committed story points compared to actual delivered story points, reflecting how well a team fulfils their planned commitments. A mature team can accurately assess their capacity and consistently deliver on their commitments from the product backlog in each iteration.
Overemphasising velocity tracking, especially in isolation, often distracts from real areas of improvement and risks misdiagnosing team performance.
5. Empowered and trusted teams perform better
Studies have long linked happiness with productivity in the workplace, with Lecioni’s job misery model highlighting the benefits of greater levels of personal autonomy and trust in the workplace – tackling feelings of irrelevance and anonymity that characterise job misery.
Just as micro-managing how tasks are done, an obsession with velocity can indicate a lack of trust.
Measuring what truly matters is a critical aspect of enabling the delivery of value to your end customer, and ensuring the sustained success of your Agile transformation.
REFERENCES.
Kronos.com
SAFe 6.0: https://scaledagileframework.com/
Lencioni, Patrick. “The Truth About Employee Engagement: A Fable About Addressing the Three Root Causes of Job Misery”. Wiley, 2007.
Conclusion
Leveraging user-centered design practices with Agile can bring numerous benefits to a company, including faster go-to-market, better user experience, and increased collaboration. However, there are common challenges to overcome, such as limited time for design, lack of documentation, and balancing short-term and long-term goals.
To overcome these challenges, companies should prioritize user research and testing, collaborate with developers and stakeholders, and leverage design sprints to include best practice user-centered design as part of their Agile processes.
With the right approach, UX and UI design can thrive in an Agile environment, leading to rapid delivery of products on time, functional, and user-friendly.
REFERENCES.
"Lean UX: Designing Great Products with Agile Teams," by Jeff Gothelf and Josh Seiden.
“Design Thinking and Agile Design, New Trends or Just Good Designs?” by Vanessa Svihla.
"Manifesto for agile software development,” Beck, K., Beedle, M., Bennekum, A. V., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas, D. (2001).
"Here Is How UX Integrates With Agile and SCRUM," by Jeff Gothelf.
About the authors
