Skip to main content

Is Agile Velocity dangerous?

Last post 06:43 pm March 20, 2024 by Daniel Wilhite
4 replies
11:40 pm March 15, 2024

Hello dear Agile folks,

My colleagues and I are seeking clarity on several concerns we have about agile project management. 

For example, it is recommended to review and estimate user stories from the backlog as a team (for example, through poker planning). However, there's been intense debate among my colleagues because some fail to see the utility of estimating tickets, given the uncertainty of which developer will pick them up. Indeed, a junior developer might take longer than a specialized senior. 

But worse, concerns have been raised about the potential downsides of estimation. Some argue that it could lead to monitoring individual developers' performance, possibly giving management grounds to dismiss underperformers. 

I do believe in Agile and all the benefits it brings to software project management, however, I'm now personally confused by the concerns of my colleagues and unsure about this aspect of the agile method. Can anyone shed light on this or provide insights into managing these concerns effectively?

Many thanks for your help!

09:08 pm March 18, 2024

given the uncertainty of which developer will pick them up. Indeed, a junior developer might take longer than a specialized senior. 

What would that so-called "senior" then do? Pick up another ticket...or help his or her fellow team members to limit and actually finish work in progress?

11:41 pm March 18, 2024

Some of these are valid concerns about estimation.

I don't think the uncertainty about who will do the work is a huge concern. If you are using group estimation techniques, this should come out in the conversation. If you build any kind of learning curve or slowness into all the backlog items, it'll average out over time.

The concern about the use of the estimate for monitoring performance or holding teams to commitments may be valid in some organizations. However, this highlights the difference between estimation and estimates. You can use estimation practices to check the size and understanding of the work without recording an estimate. If you don't write down an estimate, then there's nothing for the team to be held to.

If you're looking for alternatives, I'd recommend the flow metrics and the #NoEstimates movement. Daniel Vacanti has written three books about using flow metrics for predictability and forecasting completion of work - Actionable Agile Metrics for Predictability: An Introduction, When Will It Be Done?: Lean-Agile Forecasting to Answer Your Customers' Most Important Question, and Actionable Agile Metrics for Predictability: Volume II: Advanced Topics. Vasco Duarte's No Estimates is also a good read.

If you do want to dig into better estimation techniques, and specifically software estimation, I'd recommend Steve McConnell's Software Estimation: Demystifying the Black Art and George Dinwiddie's Software Estimation Without Guessing: Effective Planning in an Imperfect World.

At the end of the day, estimation is a tool. Estimates are a piece of data. There are benefits and risks to using a tool and benefits and liabilities to holding on to a piece of data. Maximizing the benefits while reducing the risks and liabilities can be important, and it's ultimately up to the team to decide what the best approach is in their context.

11:59 am March 19, 2024
However, there's been intense debate among my colleagues because some fail to see the utility of estimating tickets, given the uncertainty of which developer will pick them up. Indeed, a junior developer might take longer than a specialized senior. 

Hi Ivan give you an example let us consider a scenario of you travelling to your office. In this scenario story points/any estimation technique says you need to estimate the distance rather than the time you would take to reach office. The time will vary due to a lot of factors (mode of transportation, traffic conditions etc.). The idea here is that it is easier to have an agreement on the distance rather than the time it would take to reach office. 

When it comes to story points you should estimate the work (based on amount of work, complexity and risk) and you should not be thinking about who would do the work and how long will he/she would take to do it. You are right when you say that a senior developer may do it faster than a junior developer but when this work is given to a junior developer you can help him learn from the senior developer (try pair programming). There will be a learning curve for the junior developer here for sure and this is to be encouraged. If it suits move this piece of work at the start of the sprint so that you can accommodate the learning curve and at the same time, ensure the work is done by the end of the sprint. Over the next few sprints you will surely see an improvement in the work of the junior developer and probably he is able to deliver a done story independently (dont you think this is the real performance improvement).

Also you need to check linking estimates to individual performance, delivering value is the key and not how many story points a team/individual has accomplished. Estimates are used only for the purpose of forecasting (or adding some kind of guardrails when picking up work during the sprint).


06:43 pm March 20, 2024
  1. It is human nature to estimate things.  We look at a big jar of pickles and say "that's a lot of pickles" but we don't say "there are 25 pickles in that jar".  We look at a plane in the sky and say "wow, that's really high" but we don't say "that plane is at 10235 feet above sea level".  Estimates are natural for humans to use.  It helps to grasp the enormity of something.
  2. Estimates are also made at a specific point in time based upon information known at that time.  After you start working on something, there is usually new information obtained and the original estimate is no longer valid.
  3. A synonym for estimate is the word guess.  

Take the 3 things above and think about your original question and how your team feels about estimation.  It may be that you are trying to put too much emphasis on them and should step back to take another look.  Use estimates so that the Developers can then estimate if they can get some body of work done during a Sprint timebox.  Then once work begins, forget all about the estimates and focus on getting the work that produces value done. 

I second @Thomas' recommendation of Daniel S. Vacanti's work.  I have used it to help a number of teams and organizations realize just how much work is being done, how valuable it is and how much they really don't understand about how the work is done. 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.