Product teams exist to create value. The impact they create is a function of:
- The value of each feature shipped (strategy)
- The number of features shipped (team velocity)
A solid strategy and discovery are needed to make sure that each feature shipped creates impact, while high team velocity is needed to make sure that the team ships features fast and frequently.
More precisely, team velocity is the amount of work a team completes within a specific time period, typically measured in story points, tasks, or deliverables. It is used to predict future capacity and track progress.
There’s often a temptation to emphasise the importance of strategy over team velocity in PM circles, but the fact is that you need both to deliver impact.
This article focuses on how you understand your team velocity and improve it.
Why increasing team velocity is important
Increasing team velocity is important for two reasons:
- It helps you deliver more impact
- It increases your credibility inside the organization
Impact
The first point is fairly intuitive. If you ship more stuff, and each thing you ship is just as impactful, then you will have more impact.
Shipping quickly means that the cost of shipping each feature goes down, and return on investment goes up. This isn’t just about the cost of running the team, but also the opportunity cost of what else you could build, and the cost of delaying the release of features.
Credibility
Beyond the actual increase in impact that the team will have, increasing velocity is important for political reasons – stakeholders want to see high velocity, and constantly fighting for this will increase your credibility.
High team velocity feels good. New features are being shipped all the time. Customers are impressed with how the product is getting better and better. It’s exciting and highly visible to everyone.
But team velocity has a tendency to decrease as a company scales, because the code base becomes more complex as new functionality is added. Stakeholders probably don’t understand this dynamic in detail, but do see features taking longer to build. They remember and miss the speed at which things used to happen, so this naturally leads to frustration.
One common pattern is for stakeholders to blame the motivation or quality of the team if they feel velocity is low. This is dangerous because:
- It rarely leads to the real root causes of team velocity being addressed.
- It causes tension, and in the worst case people get fired for the wrong reasons.
So for both real and perceived benefits, it’s incredibly useful for PMs to have a good understanding of what team velocity is, and how to improve it.
Why teams are slow
Product teams are slow for two fundamental reasons:
- Systemic limits – persistent, structural issues that cap the rate of delivery
- Tactical interruptions – small, unpredictable interruptions that disrupt a team’s flow
Systemic limits
Every team has a theoretical top speed. We call this its systemic limit. This is set by structural reasons, for example:
- How many engineers are on the team
- How good those engineers are
- How complex the code base is
- Etc.
These reasons are fairly constant regardless of what the team is working on. Fixing these root causes requires deliberate effort from the team and wider org, and there are no quick fixes.
These reasons are often not immediately apparent, either because they are taken for granted (e.g. this is a team of 4 engineers), or not easily visible (e.g. the code complexity is high).
Tactical interruptions
On top of this, teams will rarely reach their systematic limit, because of small distractions and blockers that pop up. These might include:
- Poor documentation
- Leadership not signing off designs
- Waiting for other teams to complete work
- Bugs and support tickets distracting team members
- People getting sick
- Etc.
We call these tactical interruptions. While these can significantly slow the team down, they are generally short lived, and specific to an individual piece of work or a particular time.
Tactical interruptions can generally be avoided or mitigated through better ways of working. They also tend to be highly visible as the immediate blockers of the team. You need to be careful that fixing these doesn’t stop you working on the underlying problems that fix the team’s systemic limit.
Tackling systemic limits and tactical interruptions
Whilst it’s a helpful mental model to think of systemic limits and tactical interruptions, the reality is often fuzzy. For example:
- Needing to fix a critical bug on checkout page = tactical interruption
- Constant stream of bugs from tech debt on checkout page = systemic limit
In practice you want to deal with every tactical interruption as it appears as efficiently as possible, while at the same time diagnosing and chipping away at the systemic limits the team faces. Continuing our example:
- The immediate bug on the check out page needs to be fixed right now. This might take a few hours, and we’ll probably do it ASAP.
- We also need to find time to refactor the whole check out page to make it more stable. This might take several days or weeks. It needs to be planned and accounted for in the roadmap.
We talk about three key components to increasing team velocity, which together reduce tactical interruptions and lift systemic limits:
- Tracking how fast you ship – establishing the baseline team velocity and spotting tactical interruptions quickly.
- Holding check-ins – these drive accountability and focus on team velocity, as well as provide a forum for rapid problem solving.
- Identifying and removing systemic limits – digging deeper into the root causes that are capping team velocity, and investing to remove them.
Let’s run through each of these components in turn.
Team trackers
The first step to improving team velocity is tracking team progress. This can be done by creating a team tracker, a report which records what the engineers are working on and have delivered. This allows teams and stakeholders to take an objective look at how fast product teams are moving.
This is critical for several reasons:
- Allows problems to be spotted and addressed quickly (tactical interruptions)
- Allows you to see if action you are taking is increasing team velocity (systemic limits)
- Underpins check-ins, which drive accountability
We’ll run through two formats for team trackers:
- Delivery Review – Google Sheets
3-part report which tracks outcomes, outputs and team health - OKR Tracker – Google Sheets | Excel | Notion
Tracks team objectives, key results and output
- Delivery Review – Create a FREE account to access
3-part report which tracks outcomes, outputs and team health - OKR Tracker – Create a FREE account to access
Tracks team objectives, key results and output
You can use these off the shelf, or adapt them to your own context.
In both cases, the goal is not to give you an absolute value for team velocity (i.e. not “we have a velocity of 83!”), but to allow you to:
- See if features are being shipped as predicted
- Spot and address problems early to minimize delays
Delivery Review
A delivery review has three main sections:
- Impact metrics – the impact you want the team to drive (i.e. team success metrics)
- Delivery progress – the work the team has done
- Team context – team context that provides colour around what’s been going on in the past week
This sheet can be filled in by a PM, tech lead or delivery manager, and should take <10 minutes for a single team.
You could fill this in at any cadence you like but in practice weekly seems to work well. This is long enough for things to change (not much changes day-to-day), while still providing early signals if things start going wrong (filling this in every two weeks allows you to lose a week or two quite easily).
Basic Delivery Update template Get the delivery review template: Google Sheets
Create a FREE account to access the delivery review template (Google Sheets)
Let’s go through each section in more detail:
Impact metrics
This is where you plot the success metrics the team is trying to move. You can add in 2-3 supporting or health metrics, but you want to keep the overall number of metrics small (i.e. <5). You want a clear signal of whether or not the team is actually delivering against the objectives it has, and this will become more noise than signal if you include everything.
As the team delivers features, you expect these metrics to change, with a certain amount of lag, depending on the roll out plan and metrics selected.
Even if you don’t expect these metrics to move much week-by-week, it’s worth including them to reinforce culturally that the team should be impact-focused, and delivery is only important when it results in impact.
Delivery progress
This is where delivery is tracked. Each initiative or epic gets its own row, and each week the progress towards delivering this is tracked.
The most straightforward method is to track completed tickets or story points. For example, if an epic contains five total tickets and two are marked as “done”, the progress would be calculated as 2/5, or 40%.
This allows you to get a quick and dirty read on the trajectory of the work. If you are 40% through the time allotted to complete a piece of work, have you done 40% of the work? Or have you done more or less than that? Being able to project this early is critical, as it gives you enough time to take action to get back on course if you fall behind.
Measuring completed tickets or storypoints is a crude indicator. Tickets are different sizes, or developers could spend most of their week working on tickets that weren’t quite completed.
But despite these limitations, this method offers several key advantages:
- Simple – It’s easy and unambiguous to measure. Everyone knows what you’re talking about and the limitations of the metric.
- Early Warning – It provides early indicators of things slowing down or going off track. It gives you time to respond and before things become critical.
- Objective – This approach offers a more reliable assessment compared to subjective evaluations based on a tech lead’s opinion.
Overall, it facilitates the conversations you need to have. You don’t need perfect measurement, you need a “good enough” measurement to trigger the right conversations and make the right decisions.
Don’t let the pursuit of a perfect tracking system prevent you from taking real action. Start with a crude but objective method, remain aware of its shortcomings, and be prepared to refine your approach over time.
Team context
This section tracks some of the common root causes of team velocity. You can adapt this to your own team, but some common things to include are:
- Engineering days
- Split of work
- Risks & mitigations
Engineering days
This quickly shows the size of the team, and the impact of sickness, holidays and other absences.
Split of work
Here you can track how many tickets were completed on different objectives, and any work done on work unrelated to the team’s objectives. Ideally you want to classify every ticket worked on in one of the following categories:
- Strategic product work (planned feature work)
- Ad hoc requests (unplanned feature work)
- Fixing bugs (unplanned technical work)
- Tech debt (planned technical work)
This is hugely valuable, because it makes visible all sorts of unplanned and behind-the-scenes work that was previously invisible. Making stakeholders aware of this can really help them understand why the teams are delivering things slower than they might have expected.
Understanding this split is often the first step towards addressing systemic limits – if the team is spending 50% of its time fixing bugs, then you can set a goal to increase velocity (e.g. reduce bugs to 10% of time) and take action to get there (e.g. refactor buggy pages, triage bugs more effectively).
Risks & mitigations
It can be helpful to add a section for blockers, risks and mitigations, which you can fill in qualitatively. This forces you to reflect on what you could be doing to maintain team velocity, as well as provides more context for anyone outside the team viewing the sheet.
OKR Tracker
Another way of tracking team velocity and progress is using an OKR tracker.
This is similar to the first two sections of the Delivery Review (impact metrics and delivery progress), and formatted to map to team OKRs, so that it’s easy to read for non-technical stakeholders.
There are three main sections:
- Objective
- Key results
- Initiatives
Hustle Badger OKR template Get the OKR template: Google Sheets | Excel | Notion
Create a FREE account to access the OKR template (Google Sheets | Excel | Notion)
Objective
Here you state the overall goal for the team, and might include other context, like the PM who is the main point of contact for the team, or the time period the sheet refers to.
Key Results
Here you put your key results, which quantitatively measure your progress towards the objective. It’s good practice to include:
- Baseline – where you started the quarter at.
- Target – the goal you want to reach by the end of the cycle (e.g. quarter)
- Current – simple lookup, that returns the most recent value
- Data source – so other people can audit the data if they have questions
Initiatives
Here you track delivery. You can do this like the delivery review, by calculating a % of tickets / storypoints complete. Or if you prefer, you can have a delivery window and a simple timeline like a gantt chart.
Stakeholders often like to know when features will land, so a delivery window can work well. The trick here is to start with a large window (e.g. “June”) and make this more precise (e.g. “June 23rd”) as you get more certainty around when the feature will land.
Whether you use a delivery review, an OKR tracker or something of your own design, you’ll find that the real benefits emerge after 3-4 weeks. This is when you start to see patterns emerging from week-to-week, and reporting progress becomes a habit.
Check-ins
Tracking team velocity alone is not enough. Reporting needs to be paired with some sort of check-in where the tracker is reviewed and action is taken.
This should be a very brief meeting – perhaps 15 mins or less.
You could do this as part of a team retro, but generally benefits from being limited to:
- PM and Tech Lead
- Product leader (e.g. GPM or VP Product)
- Tech leader (e.g. Engineering Manager or VP Engineering)
This forms a small group which encourages psychological safety, whilst having a number of different perspectives (team vs. leaders, product vs tech) to make the discussion productive.
These meetings are incredibly powerful when certain conditions are met:
- You have an objective measure of progress (your team tracker)
- Everyone reviews this regularly (ideally weekly)
- You show your working to others (e.g. leadership)
- This is the basis of a collaborative, problem-solving discussion
With all these parts in place you have a highly effective process which increases team velocity by:
- Driving accountability
- Checking pacing
- Unblocking the team
Drive accountability
When you have to report publicly on your progress, you will update the tracker. Social pressure is a powerful motivator for humans!
And when you update your tracker, you’re forced to reflect on what you are reporting on – your team’s velocity. If velocity has slowed for any reason then you’ll want to be able to explain it, so you’ll naturally start investigating and looking for solutions even before someone else mentions it.
Public reporting also keeps team velocity front of mind for everyone, and reinforces it as a cultural value.
Check pacing
“I have seen far too many people who upon recognising today’s gap try very hard to determine what decision has to be made to close it. But today’s gap represents a failure of planning sometime in the past”
– Andy Grove, former CEO of Intel
By tracking your progress week-by-week, you’ll quickly be able to see the progress the team is making. You can then extrapolate this forward to see if you’ll hit the delivery windows and milestones that you’ve committed to.
Understanding your trajectory gives you time to act You want to know as soon as possible whether your team is on track to hit any deadlines, because if you are behind, this gives you as much time as possible to change things and get back on track.
Once you are very close to a target or have gone past it, there’s very little – perhaps nothing – you can do to correct things. You need as much time as possible to take action. “Forewarned is forearmed” as the saying goes.
Unblock the team
The final reason for having regular check-ins on OKRs is that this gives teams a chance to highlight blockers they are facing, and to get support from leadership on removing them.
Leaders always have a very different perspective on the difficulties a team is facing, as well as a number of levers that aren’t available to teams. For example:
- Adding new team members
- Talking peer-to-peer with leaders of other departments
- Changing scope and requirements of work
- Reprioritizing cross-cutting initiatives
High performance teams use leaders as thought partners and valuable tools to reach their goals, not just as people they report to.
Tone
As with 1:1s, these check-ins are most productive when you create enough psychological safety to have really honest conversations.
Product teams and leaders need to be working together to resolve blockers and get things moving. The more collaborative the tone, the more trust will exist between teams and leaders, and the more productive the discussion will be. When leaders give teams a hard time without helping them find solutions, check-ins can be counterproductive – teams end up dreading them and try to hide poor performance.
Part of this is recognising that whilst your goal is to move the impact metrics, you can only do this by working on the inputs: working on the best features (strategy), and shipping them fast (team velocity).
If everyone is happy with the strategy and team velocity then there is no point teams being berated for a lack of results. Uncertainty and the risk of failure cannot be removed completely, and the results will follow if the foundations are in place.
Finding your rate limiting step
Once you have started tracking team delivery and having regular check-ins, you should be spotting and proactively removing tactical interruptions. This will already make a difference to your overall team velocity.
You’ll also have a fact base that you can use to start understanding the systemic limits of team velocity. This is how fast the team can deliver on a continuous basis if it’s not affected by one-off, tactical interruptions.
A good way to think about this is that team velocity is the product of multiple factors: engineering capacity, domain expertise, code complexity and so on. To increase your team velocity, you need to work out what is the biggest limit, and remove it.
Good product and tech leaders will be doing this on a continuous basis, with the goal that each quarter their teams can deliver more than the previous quarter.
Systemic limits on team velocity set by weakest team capability Let’s look at some of the most common factors that set systemic limits on team velocity.
Factors that set systemic limits on team velocity
Here are a few things that limit team velocity:
Code complexity
If the code base is complex then even changing seemingly simple things can take a lot of time both because it’s difficult to work out what you need to change, and then because this leads to unintended consequences. Code bases get more complex over time as new features and functionality is added. This is compounded by:
- Tech debt – when teams build things in a hasty, hacky way without consideration of future development because they want to release a feature quickly in the short term. If there’s constant pressure to deliver quickly, this will slow you down considerably over time.
- Evolving principles – when engineering teams internalise commercial and product principles that were important at some point, but are no longer important (e.g. you needed 4x role types with different permissions at some point, but now you’ve focused down on 2x roles)
Developer experience
Engineers can end up spending considerable amounts of time spinning up new servers, updating libraries, waiting for code to compile and wrestling with mobile releases. Most of this can be automated or accelerated, but it requires investing time in setting up the right tooling and infrastructure.
The clarity and stability of the goal
Product teams take time to get up to speed as they get to know the code base and problem space better. Changing or ambiguous priorities therefore have large switching costs. While you might need to change tack if you suddenly gain new insights, wherever possible you want to leave teams working on the same problem for at least a quarter at a time (and if possible, much longer!).
Understanding of the problem
Product teams can deliver a lot of features without delivering much impact if they don’t understand the problem space. They’ll just be shipping “stuff” instead of shipping “stuff users want”. If a team feels like it’s spinning its wheels then it can pay to take the pressure off, do some more discovery (both qualitative and quantitative) and then kick things off again. Product team velocity doesn’t count for anything if the features delivered don’t deliver user value.
Availability of specialist skills
Some problems have well trodden solutions, but these aren’t immediately obvious to non experts – for example SEO and search. A team without the right specialist skills will go slowly as it accumulates this knowledge. Product team velocity in this instance is only as fast as the team’s learning curve.
Dependencies on other teams
Teams should be built as autonomous units of delivery – i.e. they can ship features that deliver user value without relying on the work of other teams. Whilst this isn’t always possible, especially in start ups when engineering resources are scarce, the alternative is that work is often blocked by dependencies on other teams who might not have the same priorities.
Tech lead strength
More experienced tech leads are better at designing solutions, structuring work, and amplifying the productivity of their teams. The best tech leads are both good architects and good people managers.
Engineering capacity
Velocity doesn’t scale linearly with more engineers, and often doesn’t scale at all once there are more than 6–8 engineers in a team, but small teams (2–3 engineers) will not go as fast as larger teams (4–6 engineers).
Engineering seniority
Not all engineers work at the same rate. A team of experienced engineers will work considerably faster than a team with juniors. In fact, it’s not uncommon for junior engineers to have a negative impact on product team velocity, so make sure it’s the right time to invest in them (as the future of your engineering department).
Development and Staging Environment
Investing in robust development and staging environments is critical. Poorly maintained environments can lead to significant downtime as engineers troubleshoot issues that could have been caught earlier. High-quality environments enable faster feedback loops and more reliable testing, accelerating overall delivery timelines.
Quality of Test Data and Scenarios
Teams rely on accurate and comprehensive test data to validate functionality. Low-quality or incomplete test data can lead to increased bug counts and rework, reducing velocity. Providing realistic test data and well-defined scenarios ensures smoother development and fewer iterations.
Onboarding Complexity
Bringing new team members up to speed can temporarily slow down the team. Without a streamlined onboarding process, the disruption can persist. Investing in onboarding upfront by creating a great onboarding guide and process minimizes the learning curve and ensures the team regains full velocity quickly.
Identifying the right factors
Fundamentally, if you want your teams to move faster, you need to work on the factors above. But how do you work out which factors are the limiting ones, and most important to work on?
Short answer: speak to your engineers.
Long answer: you need to have a detailed conversation with your engineers about this. This is something that they might not have explicitly thought through themselves, but should be able to provide the answers to. Set aside some time for an unrushed conversation so you can dig into details. This might take several one hour meetings to really understand in depth.
Make it clear that you are not beating them up, or questioning their capability, but want to have an honest and collaborative discussion about how to increase team velocity. You can ask questions like:
- If we wanted to ship faster, what would we need to change?
- What has changed since [2 years ago], when we seemed to ship faster?
- If we wanted to invest in increasing team velocity, where would you focus?
- If we wanted to simplify the code base, where would we start?
Whilst having an understanding of the factors that are limiting your velocity is important for PMs of all levels, you will quickly get into decisions that should really be made by leaders, as they become macro-level strategic choices. For example:
- How much time should you spend delivering value now (shipping new features) vs. expanding the capacity of the team to deliver value later (e.g. reducing technical complexity, improving developer experience)?
- What is the right mix of engineering seniority to have within a given team and across the organisation as a whole?
- How many engineers should we have right now? What is the right ratio of engineers : PMs : designers?
These are often direct trade offs, and should be made explicitly. A core part of the job of product and engineering leaders is to communicate these trade offs to other senior stakeholders and engage them in the conversation of how product team velocity can be improved.
That said, there are a number of things that PMs and stakeholders at all levels can do to have more productive conversations about product team velocity in the short term.
What PMs can do
Firstly, some advice for PMs on how to increase product team velocity:
Respect the demands of the CEO
It’s all too common for product managers to complain that stakeholders don’t understand product management, agile development and how software is built. This is because when stakeholders get frustrated with lack of progress, they can start digging into the details and suggesting approaches that don’t make sense to the engineering team.
As a PM you need to recognise that senior stakeholders are usually smart and want what they want for good reasons. You cannot ignore their demands — this will only generate more tension. You need to get past the approach they are advocating, and find out what outcome they want.
Once you’ve done that you can start having productive conversations about how to get to the outcome faster, and then stakeholders will likely become less tied to any given approach. This in turn will improve the product team velocity.
Work tightly with engineering & design
When things are going badly, it’s all too common for PMs to become lightning conductors for frustrations around the organisation. This is natural when engineering is a black box, and the PM is the only window into this.
This is dangerous for PMs as it becomes impossible for people to tell whether the problem is the PM or something deeper. The answer is to work closely with your counterparts in engineering and design, and make sure they are standing beside you to deliver any tough messages.
It’s much harder to disregard a message you don’t like when you’ve got three people from different disciplines (product, design & engineering) all saying the same thing.
Work tightly with adjacent functions
The same point is true for adjacent functions such as data, marketing and sales. When teams work in silos then each team’s resourcing and effectiveness becomes a potential source of tension.
When the whole org has a combined objective the conversation becomes more collaborative: how do we as a group get there fastest? The more allies you have, the easier it is to execute in a particular direction at speed.
Understand and translate
Being the touchpoint between the product team and the rest of the business means that PMs have to translate reality both ways. It’s critical you don’t take sides, and instead work to pull everyone together. That means translating engineering constraints and realities into something anyone can understand, as well as ensuring that engineers and designers understand the business imperatives for action and results.
Offer trade offs in scope
You often can’t say “no” to product requests, and you can’t get engineers to magically work faster than they thought possible. When the expectations on the team don’t match reality, PMs need to prepare options that trade off time, investment and scope.
Getting these out on the table allows you to have a productive conversation about what are the right trade offs for the organisation at this point. It has the added benefit that you’ll often uncover hidden assumptions that are blowing out the estimates.
Ask engineers what trade offs you’d need to make to deliver something in half the time (or faster). Once they realise the conversation is about scope and not them working harder the conversation gets interesting (and fun!).
Similarly it can help to feel out with stakeholders whether they are expecting small iterations on an existing feature, or a full build of something completely new. Bring them a solution much smaller than they expected and they’ll think you lack ambition. Bring them a solution much larger than they expected and they’ll think you’re not agile. Presenting some options helps you calibrate on best approach.
Report delivery AND impact
Some things just take a long time to build, and if you’re not showing progress, everyone gets nervous. If you can’t ship user facing changes, then make sure that whatever you are doing behind the scenes is transparent to stakeholders.
Product team velocity will appear to be slow if no one knows what you are doing or whether it helps the business.
Invest in code quality
As a PM you need to agree on a sensible allocation of time to work on reducing technical debt and refactoring code with your engineering colleagues, and advocate for this with the rest of the business. This should always be outcome driven, even if you can’t quantify it – i.e. you’re spending time now to speed up the team later, not for the intellectual satisfaction of the engineers.
This might be having dedicated sprints to refactor code, or having a budget for each sprint. Either way, this helps the codebase stay clean, manageable, and adaptable to future requirements, increasing overall team impact in the long term.
What stakeholders can do
Secondly, here’s some advice you can pass on to stakeholders, to help them engage productively in the conversation around increasing product team velocity:
Be super focused
You will always have more ideas than you have capacity to build things. You need to be super disciplined about which problems you want to focus on solving, or you’ll spread yourself so thin that you fail to achieve anything. Remember that the switching costs for product teams are very real. Put more wood behind fewer arrows.
Share as much context as possible
If you’re dictating a feature set to a team, then you give it very little room to manoeuvre. Share the outcome you want, what ideas you have to get there, and why you prefer certain options over others. Then ask for their ideas and feedback.
Chances are the team has much better ideas than you do for reaching the outcome, because they are a multi-disciplinary team of specialists. Unlock their potential — give them context.
This template might help:
Strategic Context Briefing Template: Google Docs | Notion
Create a FREE account to access the Strategic Context Briefing Template: Google Docs | Notion
Demand transparency
Teams should be able to explain why things are taking as long as they are. If they can’t, this is a real red flag. Make sure they have done enough planning and investigation to come up with a high confidence estimate, are acting as a single unit, and are all aligned on expectations, scope and approach.
This is your opportunity to understand the underlying factors that are creating systemic limits to team velocity. The more widely that people understand what these are, the better you’ll be able to align on how and when to address them.
Respect the estimates
Nothing good comes from you telling the engineers that their estimates are wrong. They’ve looked into the work, they know the code base, their estimates will be better than yours.
It’s not that you don’t want to bruise their egos, it’s that you don’t want to forego the opportunity to understand what’s driving the estimates, and open up a healthy discussion about trading reduced scope for faster delivery.
Ask for options
Push the team for options. Can you buy instead of build? Can we reduce scope to ship faster? Can we test our hypothesis without building software?
Teams can take some warming up to this, but it’s worth doing.
You’ll start to understand where the complexity lies, and make informed decisions about whether or not to tackle it, and the team will start to internalise your decision making criteria as they are exposed to it.
Recap
The speed that a product team can ship at is an important driver of the overall impact it can have. Put simple, you can’t create value if you don’t ship.
Team velocity is lowered in two broad ways:
- Tactical interruptions – short term, one-off problems that slow the team down (e.g. a feature being poorly scoped, and more complex than expected)
- Systemic limits – the underlying, structural reasons that determine how fast a team can deliver
Tactical interruptions can be limited by:
- Tacking delivery to spot problems early and address them as fast as possible
- Hold regular check ins to keep a focus on velocity and provide a forum to solve problems quickly
Systemic limits will generally require more time and investment to fix. You’ll need to:
- Track delivery to establish a baseline
- Discuss with engineers the root causes
- Invest to resolve some of these root causes
Thanks to Abdel Rahmen Makssoud for reviewing early drafts of this article.
Hustle Badger Resources
Templates
- Delivery Review – Google Sheets
- OKR Tracker – Google Sheets | Excel | Notion
- Strategic Briefing Context – Google Docs | Notion
Create a FREE account to access these templates:
* Delivery Review – Google Sheets
* OKR Tracker – Google Sheets | Excel | Notion
* Strategic Briefing Context – Google Docs | Notion
Articles
What is team velocity?
Team velocity is the speed at which a product team can ship features. Team velocity is disrupted by two types of challenges: tactical interruptions (small, one-off problems) and systemic limits (persistent, structural factors that limit team velocity). As a PM, it’s helpful to know how to improve velocity on a tactical level, and understand what are the structural issues limiting your team’s velocity overall.
How do you measure team velocity?
Team velocity is difficult to measure in absolute terms. The goal shouldn’t be to reach an absolute speed, but to continually increase the velocity of the team cycle by cycle. This can be done by identifying the systemic limits to team velocity (e.g. code complexity, developer experience) and investing to remove the biggest problems.
How do you improve team velocity?
Team velocity is disrupted by two types of problem: tactical interruptions (small, one off issues) and systemic limits (the fundamental set up of your team and technology stack). Tactical interruptions are best handled by tracking the team’s progress to identify problems early, and then having regular check-ins with product and engineering leaders to collaboratively solve these. Systemic limits can be identified by having detailed conversations with engineers about the factors that are preventing them from going faster, and then deciding how you want to invest in solving these long term.
What is team velocity in agile?
Team velocity in agile is the amount of work that the team can deliver within a given time period. This is often measured in terms of storypoints, tickets or deliverables shipped. Team velocity is a measure of how fast your team can work, and is a key input to the impact your team can deliver. All other things being equal, high velocity teams will deliver more impact than low velocity teams.
What is team velocity in scrum?
Team velocity in teams running scrum is a measure of how much the team can deliver in each sprint. This is usually measured by the number of storypoints, tickets, or deliverables. Understanding what your team velocity is allows you to forecast your capacity going forward, and set realistic targets for when you can deliver work.
How can you increase team velocity?
Team velocity is limited by two factors: systemic limits that set the underlying rate at which the team can deliver, and tactical interruptions that cause short term disruption to team velocity. Systemic limits can be difficult to diagnose, and require an investment of time and effort to remedy. The best place to start is by having in depth conversations with engineers about what is holding them back, and where they would invest if you wanted to move quicker. Tactical interruptions are usually easier to identify, and can often be mitigated by changing your ways of working. Keep a team tracker to report on team velocity, and then hold regular check-ins to discuss emerging issues and how to unblock the team.
