Every agile team wants to run faster than a speeding bullet and leap tall buildings in a single bound. In agile parlance, we all want to increase our true velocity — the amount of work we accomplish in every sprint.
Being a skeptic by nature, I say “true” because it’s easy to increase apparent velocity without really getting more done.

There’s an old saying: “Time, Quality, Scope — Choose any two.” An easy way to reduce coding time is to minimize testing. But lowering quality leads to defects, and defects increase rework. If we slash scope and oversimplify a feature, many customers won’t be able to use it. A feature that most people can’t use is mostly useless.
In practice, there are three well-worn paths to increasing true velocity: (1) Optimize scope, (2) Enhance infrastructure, and (3) Reduce rework.

  • To optimize scope, carefully select just the right set of requirements that will allow customers to use the feature, easily and effectively. No more. No less.
  • To enhance infrastructure, leverage technology and processes to reduce the human effort needed to take a feature from conception to production.
  • To reduce rework, collaborate with stakeholders to ensure the correct features are implemented correctly. 

Here are twelve key checkpoints that can help your team step forward, without taking two steps backward:


Control Scope 

  • Are we surveying customers to determine must-have threshold features? 
  • Are we implementing only the threshold features first? 
  • Are we documenting the acceptance tests before we write the code?
  • Are we implementing the simplest thing that can possibly pass the acceptance tests?

Improve Infrastructure 

  • Is our unit-test and integration-test scaffolding as helpful as it can possibly be? 
  • Is our continuous integration automation as streamlined as it can possibly be? 
  • Is our software development lifecycle process transparent and clearly understood?
  • Is our team using the best tools for the job?

Reduce Rework 

  • Are we getting feedback from customers as early as possible (preferably by providing access to a beta version)?
  • Are we re-running all acceptances tests against the final release candidate before a major release?
  • Are we writing tests to prove bugs exist before we fix them?
  • Are we documenting support case solutions in a knowledge base for future reference?
If your heartfelt answer to any of these points is “Not so much”, then maybe it’s time for a retrospective with the team, to discuss ways to work smarter and get more done.

Have you found other ways to increase velocity on your own team? If so, post a comment, and lets start the conversation!

Ted Husted is a Release Engineer for Nimble AMS. “My job is to make sure we ship everything that’s done, but not before it’s ready.” For more about Enterprise Development on Force.com, visit DreamOps.org.

Stay on top of the latest and greatest. Sign up now.

Recommended for you

Blog Subscribe




This will close in 0 seconds



This will close in 0 seconds



This will close in 0 seconds



This will close in 0 seconds


This will close in 0 seconds


This will close in 0 seconds