Sprinting on a long distance

Marcin Niebudek

I find SCRUM’s “sprint” a very intriguing name for an iteration. In the heart of agile development there is continuous delivery of a working software. To do that we time-box software development into iterations / sprints.

They have their rhythm and require different kind of discipline from our team. We become sprinters who continuously plan, test, implement, evolve architectures, deliver, improve the process, celebrate to finally be back in the starting blocks to launch another sprint. We do that iteration by iteration.

Can sprinter be a long distance runner?

A very common technique in agile projects is tracking team’s average velocity. It’s said that it should stabilize after few initial iterations on some level. This is also called finding a sustainable pace for a team, which in short means that our team members commit to just enough work to become productive without burning out to early at the same time.

I’m not going to convince you here why a sustainable pace is a good thing and why a tired developer is not going to be efficient and creative. It’s the opposite that always intrigues me in the name “sprint”.

When we sprint, we put all our energy to run a short distance (a single iteration) the best we can. However we plan our efforts differently when we are about to run a marathon of 20 iterations. So how long are we able to sprint and keep our average velocity constant?

Velocity loss

Is there a point at which the team will start to loose it’s velocity? Well the answer might be that that’s where the sustainable pace comes to mind. We do not overcommit and we in fact stop sprinting at the maximum available velocity that we can achieve to sustain the pace.

Sustainable pace or sustainable undercommitment?

So how do we distinguish sustainable pace from sustainable undercommitment? Where is that point that we know we should not commit to more work as a team without being accused of just not being willing to do more while hiding behind a very nice term of “sustainable pace”?

My answer to that is great people, trust and transparency – all being the key parts of agile development. What is yours? How do you keep it at the level everybody accepts?


  1. Kevin E. Schlabach -

    When I learned about “sprinting” from ObjectMentor (Bob Martin’s company), we implemented our sprints as 30 days with one day off for rest, planning, and review. No work was done that day. We eventually went to 2 week sprints where 1/2 day was spent in planning, review, retro… and 1/2 day was spent on “catching up” on other stuff (basically off).

    This allowed us to sprint and recover.

    Not having downtime in between sprints will drive a team into the scenario you speak of. In this situation, you have to keep tweaking velocity based on the stress levels of the team. I find that body language is the best indicator of overworking vs. sandbagging.

    Management has to be willing to accept that just because they did it last sprint, doesn’t mean they can indefinitely. That’s why we should average the last 3 sprints and plan based on trending, stress, and common sense!

  2. Harry -

    Amazingly, I just blogged on WHY we use the “Sprint” nomenclature. I think that your last point on transparency and trust are the keys to identifying when you have reached complacency and when you can take on a little more – helping your team to grow with you.
    But if you are being pushed to grow, you will develop difficulties with performance.
    Good thoughts!

  3. Tim Yevgrashyn -


    Our team works on on-going basis and so we have long running perspective of our sprints. We know our “average velocity” and… we don’t use it for planning Sprints ;-)

    We use Focus Factor instead, because we understand that our commitment during the sprint depends on different factors. So, the FF helps us to forecast some outline, based on our “team availability” budget in upcoming Sprint and “yesterday’s weather” from last sprint.

    After that we clearly identify to Product Owner what we believe we can deliver and what not… Sometimes he even asks for partial delivery of big stories, accepting that we don’t promise it.

    In general, I agree with your summary – it is all about trust and transparency.

  4. Marcin Niebudek -

    @Tim so do you apply your Focus Factor to an average velocity or how do you define this FF for your team?

    Is this identification of what can be done this time a collective “feeling” expressed by your team? Not that I don’t like the idea. I would just like to hear more about it.

    In general avg. velocity is a good hint, but in the end it’s all about an agreement between the PO and the Team right?

Leave a Reply