Richard Whiteheads' Blog

100% Velocity Is A Bad Idea

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”

This quote is one of the core principles of agile. But there's a stigma that teams should be reaching for maximum velocity every sprint, or we’re wasting time, money and should be working longer. Velocity is often used as a tool to measure how well the team are performing when “working software is the primary measure of progress” is a better way to measure how successful a team is.


Let's take a step back and understand what the velocity of an agile team is. Velocity is a measure in story points or time, of the amount of work a team can tackle during a single sprint. Velocity is calculated at the end of a sprint and our velocity and accuracy should improve over time, based on experience of the technology and finding ways to improve ways of working.

Let's say we achieved 80 of 100 available hours in a sprint, that makes our velocity 80%. If we complete 50 story points in a sprint, we have a velocity of 50. Over time we are able to refine what our velocity is and the team can understand if it's too little or not enough.

If the team are always finishing too early, they should consider increasing their velocity. If the team are always in panic mode and missing goals, they should consider decreasing it.

Panic Mode

It's right that we should be striving to be as efficient and work as well as we can and that most sprints should finish with a small sense of urgency, but aiming for 100% velocity is not a good idea.

When working on a new project, external stakeholders who are potentially paying for the project, or Project Managers can sometimes believe that the 20% of uncommitted time is a waste of their money and the team just aren't good enough.

So why do we actually need to have a sustainable pace?

Take reading a book for example. You can read it as quickly as your eyes can move, but if you do that you're likely to not understand the true meaning of the story.

If our laptop CPU is constantly working at 100%, the functional performance is actually severely reduced.

If we drive our car at maximum possible speed over a long period of time, we’ll run out of fuel quickly and eventually blow a gasket.

It's actually about science too - our brains don't work 100% efficiently, we take time to read, absorb and process things. We also need space to innovate and think of better ways to do things.


Most sprints focus purely on the delivery of a new feature but realistically every sprint will also contain:

  • Corporate overhead - things we need to do outside of the project including any unaccounted for conversations
  • Time to self-organise and help each other
  • Context switching from one task to another
  • Technical debt from previous sprints
  • Space to innovate and think of ways to build better products in better ways in the medium-long term
  • Unknown unknowns at the point of sprint planning

Constant Pace

In almost all case's it's better to maintain a steady, constant pace to get to where we want to be in good time. We often use the analogy - do we rush to get the lifeboat out or do we stop to work out how to get the lifeboat out even quicker?

Maximum velocity isn't sustainable in the long term. It can cause stress and anxiety between the team or individually, a sense of micro-management or cause the team to always overestimate stories just to buy them time. Importantly it can also result in mistakes being made, the wrong thing being built or what we’re building not to be the best it possibly can be.

So now it's clear why 100% velocity is a bad idea, here's some ways we can help reach the right velocity in our teams:

  1. Set reasonable goals. Bring an amount of work into the sprint that the ones delivering the work are comfortable with. Never compromise on quality. As long as the team achieve their goals most of the time, that’s ok as over the project it will balance out.
  2. Establish a culture where we can be honest and transparent, commit together, win together and lose together. Don't punish the team for falling behind, but find ways to improve.
  3. Review velocity regularly at least every other sprint, and adapt accordingly to the environment and agree on velocity with the entire team
  4. Introduce clean up stories to deal with technical debt and improve quality
  5. Reduce meetings that aren’t going to be productive for what you need to achieve
  6. Learn to say 'no' to small, regular scope creep, or we risk taking on too much quietly

Positive Outcome

If we work at a pace that the team are comfortable with, it means we can maintain that pace for longer, encourages a transparent culture and what we’re building isn’t always rushed and is always of high quality. It brings the team together to help improve, learn from each other and ultimately that positive culture will be relayed back into what they are building.

Yes teams should be busy, feel challenged and strive to produce amazing products as long as it’s done in a sustainable way where there is a positive, hard working culture, motivated teams and happy customers.

I’d love to hear more about how you manage velocity in your teams over the course of a project, drop me a comment below!

Scrum Day London 2019–A Quick Review

After a successful and enlightening Scrum Day London last year, I thought it was well worth a visit again in 2019 - but this time with 5 of us from Adatis instead of 2, and the opportunity to present at one of the keynotes!

This is the only conference in London that’s solely dedicated to Scrum, so it’s great to bring so many of us together and based on experience from last year, it’s well worth it to hear about other peoples stories.

There was an incredible array and diversity of speakers which I can honestly say provoked some real thought about the way we work - from understanding the way customers think - to how important our culture is - to understanding self-organising teams. 



I always hope to leave events taking away a couple of key learning and things to go away and think about, so here's a look at how the day went and some of my highlights.

Marnie McCormack: Get customers involved as early as we can in what we’re building. It's so important to ensure we're producing the right product. There's a strong imbalance between those that produce the product and those than use it. We often try and bridge this gap with a Product Owner but we should be asking our Product Owner to invite customers to work with us to stop them being invisible and causing disconnected goals.

Ade Shokoya: I’ve always enjoy listening to Ades talks and genuinely look forward to them as there’s so much passion and thought provoking content. This time it was all about Culture and how do we adapt to environments where we don't know what we don't know? We are individually complicated and every team will work in different ways - we can't just copy others because we don't know if it's going to work. Ade gave a great talk about why we need to embed culture in what we do and avoid using ‘zombie scrum’. Here’s some ways we can do this:

1) We need to create psychological and emotional safety: Somewhere we can express our thoughts and opinions, where people feel safe to be themselves.
2) Show vulnerability: We’ve all made mistakes – it’s how we learn. It’s fine to say we’re vulnerable instead of a know-it-all.
3) Purpose: People are not resources - we feel and act differently thorough the day. How many of us want to get to work at 9am, head down, 5pm go home with nothing exciting, innovative, creating happing? A person should recognize and celebrate their successes, have space to think, innovate and help others.

We need culture to support our business and if we create a good culture within our teams, that will radiate beyond just development but to our customers, recruitment, retainment and wellbeing.

Kamil Sabatowski: Self Organising teams are something we strive for and not something to achieve and walk away from. If we achieve the right culture - we are half way there but even if the ideal team become self-organising - will that remain the case and our work is done? No. Even if we achieve the ultimate self-organising team we can still lose it. So it's something we strive for, and when we get there - hold on to it and always find ways we can improve.

Martin Hinshelwood: Scrum vs Kanban or Scrum and Kanban: Here I learnt how we can use Scrum and Kanban together to create better focus. This is not a simple approach for new teams but is complex and rewarding. In Scrum anyone can pick up a task and work on it but we can effectively use Kanban to create better focus on higher priorities during the sprint by a) Limit work in progress – have a set number of tasks in each state at a given time b) Those items in Progress are actively being worked on and addressed by the team c) Inspect & Adapt – constantly improving and refining our stories and process to see what is the ideal theme for the team



It was an incredibly well organised event that had an amazing atmosphere and everyone seemed to have been left with food for thought. From the moment tickets were bought we were kept up to date with the latest developments and schedule. The organising team created an uplifting and positive vibe all day long which keeps a smile on every ones faces after a long day of learning!

Food was outstanding and plentiful with an endless supply of coffee and plenty of beer and wine to finish off with at the end.

It was great to have so many Scrum Masters in one place and mix with others from different countries and industries and learn about their experiences. I look forward to trying out and sharing some new ideas with my teams over the next few months.

Thank you Adkaditi for organising – see you next year!!

Foundations of Agile Development

It's nearly Christmas! The perfect time to get busy buying presents, decorate our homes and to look back at our achievements over the past year.

Agile teams should also take a moment to reflect and celebrate their own achievements and remind ourselves of its original values.

I've been reading the BCS Agile Foundations book and have found it refreshing to take a step back and reflect on what the roots of agile development are and how it's used within the teams I work with.

Agile teams often find themselves starting out on the right foot but quickly focus on trying to churn out as much work as possible, as quickly as they can to meet customer demand and forgetting about everything else. But this isn't what being agile is all about.

Agile is a people first, value first model with a key focus on quality. Here's how it's often portrayed

  • Immediate return on investment
  • Agile doesn't require much planning
  • Blame the agile team if they don't finish everything
  • Quickly put code together with little thought or design

Here's a brief look at the 4 agile values and their 12 principles to take us back to the foundations of agile development.

Agile Values

1. Individuals and Interactions Over Processes and Tools

Focus on individuals communication to create a strong team that is focused, over following strict rules and using tools that cause a distraction because that's 'just how it's done here'

2. Working Software Over Comprehensive Documentation

Value and quality are top priority in anything agile. It's up to the customer to define what working software (UAT) means and the Product Owner to drive it's value. Documentation still needs to be done but not at the sacrifice of working software.

3. Customer Collaboration Over Contract Negotiation

Work with customers as much as possible, ask for feedback and keep them involved. This is the best way to guarantee we are building the right thing at the right time. We need a form of contract but it's important to understand that even though budget and quality are fixed, features are likely to change.

4. Responding to Change Over Following a Plan

The team commits the work in a sprint, and gets it done. The team decided what their definition of done is at the start. This means every sprint we are able to change direction of what we're building. We follow are a plan but we welcome changes in that plan.

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

It's easier said than done to achieve all of these so should be a pursuit for all of us, but if we use these as the guide they were intended, we’re on the way to creating better products and better teams.

10 Ways To Improve Every Backlog

Every team I’ve worked with have approached their product backlog in different ways. It’s always surprising to see how much each team differentiates, when from the outside we should all follow a similar method right?

Over time every team, with experience, will work together to find out what works for them so there’s not a one-size fits all, but here’s some tips that can be picked up and applied to any backlog.

# Use user stories

The classic story format ‘As a …. I want to….. so that….’ has been tried and tested since the beginning of scrum. It’s the simplified but most effective way of capturing the value in a story by making it clear who the user is, what they want, and why they want it. I’ll be using this until I can find something better.

# Monitor the size of your backlog

Backlogs that contain 100s of stories become frustrating and painful to manage and it’s easy to loose site of everything that it contains. Is story 199 of 200 REALLY a priority for the product? It’s likely most of the stories at the bottom will remain at the bottom for a long time because by the time you get to them, something of more priority will have come up.

The tip here is: make sure you only have stories you need on the backlog – archive the rest. Backlog refinement sessions are a good time to do this. 

# Welcome the team to add to the backlog

My view is that anyone in a team team should be allowed to add to the product backlog but it is the Product Owner who chooses it’s priority. New ideas should be valued regardless of source; a developer may have discovered a more efficient way to do something or had an idea for an amazing new feature, but it would help the Product Owner by having a place, or a ‘tag’ on those stories which they can refer to during refinement.

# Keep it in priority order

This should be an obvious one. Your backlog should always been in priority order. This should be driven by the Product Owner but often needing input and guidance from the team.

When entering sprint planning the team should be able to pick the stories from the top of the backlog with confidence the Product Owner has already decided it’s highest priority for the sprint.

# Make it transparent

Everyone in the team should be able to see and have ready access the the backlog; Developers, Scrum Master and Product Owner. It’s valuable for everyone to see the vision for the product, what is likely to come up next and empower the team to contribute to that vision. I’ve seen too many times where the Product Owner doesn’t have access and someone manages the backlog on their behalf and am puzzled as to how this is possible.

# Regularly groom it

Backlogs are a living, breathing to-do list. The team should (driven by the Product Owner) often inspect the backlog and use the stories as talking points so everyone can really understand the Product Owners vision for that story. The team should also be able to relay back what are the dependencies,blockers, or ask questions before going into sprint planning.

# Estimate at a high level

In scrum we’re told to only really care about what’s in this sprint and a bit about what’s in next sprint. However business’s always want to know how much work there is roughly and how long roughly it will take.

We need a release plan. Each story should have a high level estimate of work so the Product Owner can relay to stakeholders when they may be able to use their shiny new feature.

This should be done as a team – not the Product Owner or a single developer.

If anyone wants to know exact delivery dates for something in the distant future, say ‘I don’t know, that’s not agile’

# Capture the detail

Every story should contain a user story, requirements to complete it (acceptance criteria), the definition of done and any other detail needed that will help deliver the story. It’s likely there has been some conversations about each story so write down the important parts from the conversation as we’re likely to forget when we come to work on it.

# Keep stories small

If you use planning poker or at least the Fibonacci number series to put an effort against a story, the higher the estimate, the less confidence we have in it.

Break down the stories until you are comfortable it can be delivered in the time you’ve estimated. Keep in mind that story still needs to deliver value.

# Most detail in prioritised stories

The backlog is in priority order and now it’s time to refine those stories. We should only refine stories looking 2-3 sprints ahead. Being agile, the priorities are likely to change. The higher priority the story, the more attention and detail it should get and this should gradually reduce as you move down the backlog.

Scrum Master Checklist

I often use to-do lists to keep track of tasks on paper rather than in my head. I have a Scrum Master checklist that I go through to help keep on top of a project, so I thought I would share this with my fellow Scrum Masters.

They’re all as important as each other so not really in priority order and are subject to change as we learn more.

  1. Are there any immediate blockers that need to be resolved?
  2. What are the highest risks and what can I do to minimize them?
  3. Is anything distracting my team from the sprint?
  4. Are my team uplifted, productive and communicating regularly?
  5. Check progress towards sprint goal
  6. Check burndown -> are we on track? if not, ACTION
  7. Check status of backlog. Do we need refinement?
  8. Is the project budget on track?
  9. Do I need to radiate information to anyone? (project status report, meeting minutes)
  10. Do I need assistance from anyone?
  11. Prepare for Scrum ceremonies
  12. Note any retrospective points
  13. Check in on teams holiday plans

I’ve tried to keep it simple so it doesn’t become a burden but should be enough to cover the ground work. If you have anything else you think should be added, altered or removed I'd love to hear feedback from your experience.

Consultancy Scrum is very different from Traditional Scrum

Having come from a traditional Scrum background and moving into consultancy Scrum, I'd quickly noticed that although the problem it’s trying to solve is the same, the approach is vastly different and more complicated than the former.

Almost all of the articles and books out there are focused on traditional Scrum so it’s not as simple as reading a book and being able to make a start tomorrow. In this blog post I'd like to write about the most common differences that I've come across so far.

Traditionally companies use Scrum to manage and develop their own products using their own resources - they’re facing in-wards. Stakeholders, Product Owner, Scrum Master and the Scrum Team are all part of a single company. Sprints are unlimited, budgets and resources managed by a single entity and the teams never changed.

Using Scrum in a consultancy to deliver a project rather than a product means there are a few key differences in the way we approach the framework but these subtle huge differences can be the making or breaking of a project. We need the process to work, and work well every time, for both the client and vendor.

agileIt needs to have supermaneuverability - ‘the ability of aircraft to maintain pilot control and perform maneuvers in situations and ways exceeding those that are possible using purely aerodynamic mechanisms,’ where the purely aerodynamic mechanisms are those of traditional Scrum.

Non-the less, the goal of Scrum doesn’t change: to get the most important stuff done first with more frequent, demonstrable, releasable software.

Below is a summary of the key differences and challenges there are with consultancy Scrum vs traditional Scrum

Traditional ScrumConsultancy Scrum
Inward facing (single company and product) Outward facing (external project and client)
Product based Project based
Product Owner experienced and knowledgeable about Scrum and the product Product Owner often needs to be identified and requires training about Scrum
Internal Product Owner External Product Owner
Developers are on a single team Developers often on multiple projects
Budget internally managed and fixed Billed on time. Time = money
Organisation has adopted agile Client often not interested in methods used to manage the project
Unlimited number of sprints Time/budget restraints
Constant velocity that’s easily calculated Velocity more difficult to gauge due to shorter projects
Team members are always the same Teams can be as agile as Scrum itself
Aligned on estimates Estimates often require re-calibrating

Consultancy Scrum is a bigger challenge than traditional Scrum because it’s more fluid, reliant on external input and every project has different dynamics. But that forces the teams to become more efficient and streamlined – and fast.

They can’t spend time in meetings about meetings or have retrospectives that last half a day. Every sprint planning, stand-up and retrospective has a direct impact on if the project is successful.

So where’s the best place to start with applying Scrum to a project? That’s a tough one and to be honest, all aspects of Scrum need care and attention. I know that putting the effort in at the beginning;  identifying and training the Product Owner, having clear project goals across everyone involved, a well groomed and beautiful backlog and as always – identifying those risks and dependencies with a plan to mitigate as early as possible is the best place to start (not forgetting having a great team to work with!)

Different teams and companies will have different approaches, it’s up to the team and Scrum Master to find what works for them.

If anyone knows of any other differences, has any advice or horror stories, it would be great to hear from you!