Three Tips to Double Your Team’s Agile Velocity

As an Agile team matures, you start to see dailies running efficiently, improved participation, and Sprint Retros and Sprint Plannings that run smoothly. Everyone in the organization can see the benefits of the Agile approach at work. Getting to this point can take time; I encourage you to read our first post to review ways to work through some of the common challenges in adopting Agile.

This is the exact time when you have to evolve your Agile practice further, shift your focus from achieving the basics to delivering the business outcomes desired: 

• Faster releases of a useable product to users and customers

• Higher product quality

• Increased ROI

• Improved productivity (and a resulting improvement in team morale)

• Increased control and predictability over the process

• Improved customer satisfaction

By evolving your Agile practice, you will realize even more and better business outcomes. In this post, we will look at three essential ways you can double your team’s Agile velocity.

 

1. Measure Agile velocity with story points

Sometimes, having mastered Scrum events and other basic Agile practices, teams can fall back into a comfort zone. They can often forget to tackle the more complex aspects of a Scrum team, such as tracking velocity with story points.

 

Why are story points and tracking the team’s Agile velocity so important? 

When you are project planning or monitoring your project’s progress, you must clearly understand how much work you can get done. This is the most basic foundation of a robust Agile approach.  

You can realize many benefits of tracking your team’s Agile velocity, including:

• Scrum Masters/Product Owners can strategically plan their project work. 

• You can better defend and set realistic expectations for the time of your development team, Product Owner, and the organization. 

I can’t stress enough how important this is. If the Scrum team can get their velocity right, then you can rapidly inform the organization’s stakeholders what projects can get done, with the resources in place. You can also more easily and rapidly respond about which projects can’t get done. This is a true game-changer.  

 

Use story points to increase Agile velocity

Align your team around story points, making sure they understand what they are and why they are useful. 

Hint: Always remind them that story points are a relative unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

• Estimation is an art, and we learn and improve by practicing. Your team will get better with time.  Encourage them to practice for two or three sprints before starting to make firm commitments based on story points. Make sure that, while you’re practicing, you incorporate insights from past iterations as part of your team’s knowledge. I suggest doing this by including the review of their estimates as a specific agenda item in your Retrospectives.

• Work closely with your Product Owner. When your team begins the estimation process, they’re likely to have questions for the Product Owner about requirements and user stories. And that’s good: those questions help the entire team develop a clearer understanding of the work 

• Agile estimation is a team sport. Involving everyone (developers, designers, testers, deployers, and more) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story.

• Use planning poker.  Story points are best used in a Fibonacci-like format: 1, 2, 3, 5, 8, 13, 20, 40, 100. This relative estimation approach is helpful because it pushes the team to make tough decisions around the difficulty or the effort a product backlog item will have, not so much on the hours.

• Once you agree on the relative effort of each story point value, as a team, you can assign points quickly without much debate, after a couple of times.

 

2. Plan sprints around team capacity and avoid overcommitment

Often, Agile teams don’t see overcommitting as a significant issue, because they believe that overcommitting can give them more of a runway if any of their current tickets become blocked. However, overcommitting can create unnecessary pressure and set unrealistic expectations. 

It is vital that you do not overload the queue with stories you know the team can’t complete. Being true to what the team can accomplish in a sprint makes it easier for Scrum Masters and Product Owners to realistically plan for future sprints based on actual bandwidth. This, in turn, leads to an increase in your team’s Agile velocity. I encourage Scrum teams to communicate with their Product Owners, asking to re-prioritize the sprint work if needed, so the team can focus on the most critical items and tackle impediments head-on.

Here are some tips to avoid overcommitting:

• Make sure you are aware of your team’s capacity for the sprint. 

• Prioritize the larger product backlog items first to ensure you will have plenty of time to tackle them.

• As soon as you have identified a product backlog item that will likely not make the release, communicate this to the Scrum Masters and Product Owners.   

• If you did miss the mark in estimating a product backlog item, communicate that to the Product Owners. Work with them to remove an item from the sprint or push the backlog item out further so the team can complete the existing sprint.  

• Be sure to discuss important things within the Retrospective, such as tickets removed from the sprint. Be sure everyone understands why that happened so the team can learn from it. 

• Refer back to the first bullet in this list. Ask yourself and your team, “Can I/we realistically take on this many story points?” Let’s be honest with ourselves, the Product Owners, and the team. We can’t make the impossible possible!

 

3. Stick to the agreed scope of the committed ticket for the sprint (or, how to avoid auto-imposed scope creep)

Scope creep happens in many, often well-intentioned, ways. For instance, a team member might say, “Since I am here, I might as well…” It might make sense in the moment to solve any code issues you find while you’re working on a ticket, but it can disrupt the healthy flow of the sprint and can often cause re-work. 

What should happen instead of adding extra work to an existing ticket? When a developer discovers that additional work might be needed, create a new ticket. By sticking to the agreed-upon scope of the ticket, your Agile team can focus on delivering what was requested, and only what was requested. Doing this helps the team stay on task and ultimately improves velocity.

A related best practice is to avoid blending tickets. Blending related tickets into a single ticket defeats the purpose of breaking extensive functionality into smaller items. When you break larger functionality into smaller items, you make it possible for your team to deliver faster. Workflows more smoothly between team members. Code reviewers can be more efficient. You decrease the risk of technical conflicts with existing code, and more importantly, the time spent resolving those conflicts. You also get feedback faster on the specific functionality delivered. Blending tickets may be tempting, but it can lead you to undermine all the great work you’ve done on building an Agile approach.

 

To increase Agile velocity, focus your team on business outcomes

To achieve greater velocity, your Agile team must extend its focus beyond outputs to include business outcomes. The tips I’ve shared in this blog will help you realize a significant improvement in productivity and team morale. More importantly, you’ll gain more control and predictability over the entire process. By sticking to story points estimation, committing only to what can be realistically achieved in a sprint, and avoiding scope creep on the committed tickets for the sprint, your team will learn how to accurately predict the sprint outcome. As your team becomes faster and more accurate, the entire organization will gain more visibility and greater confidence in delivery dates for requested functionality or products. For your stakeholders, this is priceless.