InfoQ

News

How Long Should You Sprint For?

Posted by Mark Levison on May 20, 2008 07:58 AM

Community
Agile
Topics
Agile Techniques ,
Adopting Agile
Tags
Scrum

What factors influence the length of your sprint? When you're trying to pick a length between two days and six weeks what factors should you take into consideration? Ash Tengshe, Agile Coach at Capital One, suggests that choosing a sprint length is a matter of balancing forces that want to shorten vs. lengthen the sprint.

Forces that tend to Shorten

  • No Changes: The rule of no scope changes during the current sprint. This means the organization must be able to wait on average 1 1/2 sprints before asking for a change.
  • Closure: The end of a sprint creates a good feeling, it's a chance to celebrate the team's accomplishments before starting all over again (Ilja Preuss).
  • Feedback: This is the chance to reflect on the work completed and how the team performed. More frequent feedback means smaller course corrections each time. (Ilja Preuss)
  • ROI: Every sprint provides an opportunity to deploy new features. (Ilja Preuss)
  • Reliability of Commitment: With shorter sprints it's easier to tell if the commitment can be meet. With longer sprints team the team is more likely to over-commit, thinking they should be able to get that story done. (Paul Oldfield).

Forces that tend to Lengthen

  • Getting to "Done": In some environments it can be technically challenging to get a story finished in a short sprint. (Ash Tengshe). (A previous InfoQ item talked about getting to "done")

Perhaps most importantly Dmitry Beransky reminds us that all of the forces still subservient to the team and what they find works for them.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
ONE WEEK by Clinton Begin Posted May 20, 2008 10:23 AM
Re: ONE WEEK by Bruce Rennie Posted May 20, 2008 11:34 AM
Re: ONE WEEK by Mark Levison Posted May 21, 2008 9:14 AM
  1. Back to top

    ONE WEEK

    May 20, 2008 10:23 AM by Clinton Begin

    So what's the next question? Clinton ;-)

  2. Back to top

    Re: ONE WEEK

    May 20, 2008 11:34 AM by Bruce Rennie

    I've worked in projects with sprints anywhere from 1 to 6 weeks and haven't really observed any issues that can't be overcome, with any length.

    I suppose the general rule should be "As short as you can manage" simply to allow yourself more opportunity for feedback and correction. But I wouldn't reject the idea of a 6-week sprint just on the basis of that alone.

  3. Back to top

    Re: ONE WEEK

    May 21, 2008 9:14 AM by Mark Levison

    Bruce - I think that Dmitry hit the nail on the head. Whatever works for your team. However I would be concerned with sprints that were longer than **three** weeks that they might devolve into a mini-waterfall. I've seen cases where there was a handoff to QA within the sprint.

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.