Agile Development: From Velocity to Value

(4 min read)

In any software development project, estimating and committing are both important — but what some teams fail to understand is that they are fundamentally separate activities. When Estimates are conflated with Commitments, the project could be set up for failure.?

To unpack this, we need to clearly define those terms:

• Estimates are educated guesses about the amount of effort that a given user story will take to complete
• Commitments are dedications to actually completing a given task, within a time frame

When an EyeCue Lab team investigates a user story, we estimate how much effort it will take to complete. At the beginning of a sprint, the team then commits to completing that story in that sprint. As these commitments are checked off, they add to the overall Velocity of the team:

• Velocity is an agile metric that describes the amount of work a team can expect to complete within a single iteration or sprint.

Importantly, velocity is a measure of effort, not stakeholder value. Velocity is useful as a way to forecast the pace of development and make reasonable plans. However, the goal of providing better value for the stakeholder sometimes leads teams to spend a lot of effort on increasing their velocity — and that’s not the same thing as increasing value.

Velocity Inflation

Every time, this artificial inflation of velocity turns out to be counterproductive. First, it directly leads to a buildup of tech debt, weighing down any future development or maintenance. It also generates experience debt. By bloating a system with code and features that don't deliver real value, the team ends up creating a worse user experience.

But the biggest casualty of the push to increase velocity is the team’s ability to prioritize and do discovery work. (This is sometimes thought of as the “non-technical” side of product development.) Discovery helps teams learn which features and experiences will truly deliver customer value, and prioritization finds the best time to work on an initiative.

...the biggest casualty of the push to increase velocity is the team’s ability to prioritize and do discovery work.

Discovery and prioritization are key in maximizing the stakeholder value produced with a given amount of effort. A team that recognizes the importance of these aspects of development can often produce impressive insights and innovative solutions.

Meeting Commitments

Having all this said, it’s still a fundamental agile practice to commit to the prioritized work at the start of a sprint — and then to fully complete that work at the sprint’s conclusion. Strong agile teams complete (or exceed) their sprint commitments, and deliver a positive iteration on the product at the end of each sprint.

Meeting sprint commitments isn’t trivial. There are many obstacles that can get in the way:

• New team members take time to understand work styles, methods, and collaboration dynamics.
• A team working with new technologies or other “unknown unknowns” may find their estimates thrown off by these knowledge gaps, leading to over-committing or under-committing.
• A challenging product owner and business culture may pressure the team to commit beyond their capabilities.
• Less experienced developers may not fully know their own constraints.
• The estimates for features in MVP are different for a product in production.

EyeCue Tactics to Improve Commitment Success

Here are five practices that our teams utilize to achieve their sprint commitments:

1. Prioritize continuous improvement to team collaboration and communication during scrum meetings.
2. Use spikes to address technical risks. Spikes are user stories designed to validate technical unknowns and risks. When a spike succeeds, the business value delivered is knowledge: a better understanding of how to design, prioritize, and deliver user stories.
3. Split complex user stories into smaller, simpler ones.
4. Define bite-sized commitments instead of over-promising.
5. Swarm to complete the highest priorities.

Keep the Goal in Sight

Many organizations lose sight of the real goal of agile ways of working. They get stuck focusing on improving activities and outputs, instead of improving business outcomes.?But agile is a means to an end, not the end itself.

Given all of this, how do we measure the return on this kind of investment — that is, the ROI for agile work? We ask these kinds of questions, identifying Objectives and Key Results (OKRs):

• Does it have a notable effect on the quality of the outcome?
• Does it enhance the ability to manage priorities, as external factors change?
• Does it lead to shorter delivery times?
• Does it improve customer satisfaction?
• Does it reduce risk in the changing market landscape?
• Does it result in increased market share?
• Does it increase project visibility, by increasing stakeholders’ participation in the project?
• Does it improve team morale and productivity?

When you ask these questions in your own work, what answers do you find? Do those answers change the way you think about your projects? Let us know in the comments.