The Two-Week Sprint Monster

11 July 2014


I recently received a diagram that illustrated the integration of the Scrum framework in a government software development plan. It was well put together, but I noticed a peculiar item: The diagram showed six-week sprints. Six-week sprints are well outside the established and accepted four-week max timebox for a Scrum sprint. Everyone familiar with Scrum knows that. What was interesting to me was why an otherwise good Scrum diagram showed such an obvious violation of Scrum principles.

I realize that the four-week sprint maximum is somewhat arbitrary. There is really no invisible four-week wall out there that will cause a Scrum project to self-destroy if it goes longer. The reality, however, is that Scrum, like all other Agile frameworks, has as a goal the delivery of working products in short intervals. So what is a short interval, and why do people resist them?

Agile derived its principles, its ethos, from Lean manufacturing processes. Agile is the non-manufacturing project version of Lean manufacturing processes. Scrum, meanwhile, is a form of -- a flavor of -- Agile. Now, in this article when I refer to Lean I am talking about the Lean manufacturing processes as applied by companies such as Toyota and Boeing Aircraft, to name a few. I am not referring to the Lean software framework, which is another framework under Agile. In my opinion it is unfortunate that they use the same name -- but I digress.

So, going back to my point, Scrum is a framework that complies -- or should comply -- with Agile methods. Agile has 12 principles, and two are basic:
  1. The "highest priority is to satisfy the customer through early and continuous delivery of valuable software."
  2. We should "deliver working software frequently . . . with a preference to the shorter timescale."
As you can see, Agile principles - as well as Lean principles -- strive for short intervals to deliver working products, and the shorter the better.

In Scrum, the shorter the sprint (plan/do/check cycle, in Lean manufacturing terms), the more effective the process control. Long sprints are counter to the Agile ethos. Waiting six weeks to realize you are on the wrong track or that your timeline is off can put the project in jeopardy. Checking progress and establishing backlog items as completed, or not completed, every two weeks is much better. Short sprints eliminate surprises and eliminate waste -- which is one of the main goals of Scrum. Short sprints also allow the team to deliver quality, working, tested, and documented functionality to the customer more quickly. And that is the main measure of success in Agile.

I realize a lot of new Scrum teams are reluctant to tackle two-week sprints. If you are new to Scrum, the natural tendency when given a timeline is to pressure yourself to complete the entire project within that timeline. The sprint timebox should not be viewed as a deadline to finish something. A sprint should be viewed as a simple time span of opportunity for the team to deliver some functionality. The team should decide what they can accomplish within this time span. That is an essential element of Scrum. We should not say, "We have a two-week sprint to finish the module," but instead we should ask the team, "How much of this module can we get done in a two-week sprint?" Once the "how much" is answered -- by the team -- we have our sprint backlog items set.

This is a total paradigm shift from traditional project management and from Waterfall. But it works. What you will get is a team that produces quality, tested, documented functionality that meets the customer's expectations, every two weeks. We need to keep in mind that the success of Scrum and other Agile frameworks is their ability to achieve customer satisfaction quickly. Customer satisfaction can be reached if we frequently deliver quality, working software that meets the need. Scrum presents us with an excellent framework to achieve that. We just need to keep all the principles in mind as we apply the framework.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (2 ratings)

Comments

Koen van der Pasch, CSP,CSM,CSPO, 7/11/2014 1:10:29 AM
When transforming a team to Scrum I always, always advice them to go for two week sprints. They are afraid of the extra overhead but the feedback loop to their own work and work practices should be as short as possible when they are still fresh and ignorant in Scrum.

I find that the two week sprints are the best way for the team to keep improving themselves early. Things like the layout of the Scrum board, the way they do the review and the retrospective and even the way they handle the daily Scrum are easier to change when working in short sprints.

It usually takes a couple of sprints to get that right (forming) then a couple sprints more to get up to speed (storming) and by that time you can make a well informed decission whether to continue with 2 week sprints or change to a longer cadans.
Ashvin Gondalia, CSM, 7/11/2014 9:20:36 AM
I agree to Koen, mostly team is afraid on work load in two weeks sprint. But if we plan better it will not give burden but it will give a bit cool review meetings.

This requires a bit experience scrum team with enough maturity on processes and required every dev. Member to identify and circulate impediments on very early stage
David Grant, CSP,CSM, 7/15/2014 6:58:55 AM
It's worth mentioning that XP also favours shorter iterations, but of only one week.

The thing I like most about short iterations is that it casts a bright light on problems lurking in the shadows. If short iterations aren't working, it's usually a good sign that something in your development process is amiss.
Syed Ali, CSP,CSM, 7/15/2014 12:08:10 PM
I had the same situation in one of my project where the team was afraid to commit on a two weeks sprint to deliver a shippable product. But as explained by Gilbert, the objective of sprint is not to complete a module 100% of its entire function but the message to the team was "lets plan how much we can deliver to the business that can be used in a live environment without breaking existing functions". After two successful sprints, the team learnt the process so quickly and became a self organized in terms of estimations, managing the sprint scope and working with product owner for demos etc. I think it is a matter of how we cultivate the Scrum culture into the organization where people understand the flexibility and process of an Agile/Scrum development approach.
Tim Baffa, CSM, 7/22/2014 9:18:14 AM
In my experience, longer iterations often hide inefficiencies and constraints that shorter iterations bring to light.

Also, teams tend to initially treat iterations as mini-waterfalls, and longer iterations (4+ weeks) encourage such behavior and lengthen the feedback loop.

You must Login or Signup to comment.

 

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.