Why are we sprinting?


A few weeks back I asked this question on a very popular Agile and Lean LinkedIn Group:

10 years ago not many companies delivered value every month and Scrum really helped the industry with the concept of sprint. People started thinking in terms of vertical slices of value rather than systems and started to deliver value often, it was a great step forward towards agility.

Today most shops do 2 weeks sprints and it is commonly accepted that smaller batches are better than larger ones as they are less risky and also allow for earlier benefit realisation.

I understand how the concept of sprint has helped the industry become more agile and lean, but, and there is a but.

Why have sprints today? Why create artificial deadlines? Why create a minimum batch size, be it one week, two weeks or whatever it is?

If I am a mature organisation, I probably have cut delivery transaction costs and have a good strategy for continuous delivery and I am able to release whenever I want with little effort and risk. Why can’t I release when I have value to deliver?

Can anybody give me a valid reason for having sprints?

The topic became popular with a total of 35 thumbs up and 85 comments (including my replies)

Reading the answers, I am not only more and more convinced that sprints are unnecessary and dangerous artificial deadlines, but I am starting to think that in some agile practitioners thinking, the scrum guide has replaced the true reasons for agility.

If you have better reasons why we should always sprint, please add them as a comment, I am still hopeful I have missed something and want to learn.







3 thoughts on “Why are we sprinting?

  1. Well, my guess here is simple – sprints give management some sort of capability to plan ahead.
    Sure, some of us can release daily and according to need, working only on what is currently the most important thing – which is ok to be done when done.
    But, in some other cases, Someone needs to be able to guess a timeline – a salesperson that promises a customer “We can have this feature by next June”, or the product owner needs to be able to say “This is our roadmap for the next year. it might change, but that’s where we’re currently aiming”.
    In such cases, sprints are an acceptable substitute for planning man-days (which didn’t work all that either) – by using sprints, a team can say “here’s roughly the amount of work we get done by time-unit”.

    Another thing sprints gives a team is a structured opportunity to stop and reflect for a while – some organizations are mature enough to have self reflection all the time. I would guess most aren’t. For those teams that could improve on this aspect – having a regular interval to do so is great.

    So, are sprints useful as a deadline for a batch of work? Unless you have long release cycles (which still happens despite the assumption of continuous delivery), it isn’t. But it’s useful for other things.

  2. I don’t use Sprints. Never did. I may use the word where people are used to using it, not to disturb too much too start with.
    I use ‘Delivery Cycles’, which may have any length but never more than two weeks. Of course, unless we have a very good reason for longer, but I’ve never seen a good reason, yet.

    Short deadlines a good, because they create a Timebox (we don’t have more time than the Timebox), which is more efficient than a FeatureBox. A FeatureBox being the opposite of a Timebox: Waiting until it’s ready, in which case Parkinson’s Law (“People use the time available”) works to it’s max: “We can use all the time of the world”. Distant deadlines don’t work, because of the Student Syndrome.

    As a goal of a Delivery, we choose to deliver What, to Whom, and Why, in order to get the feedback we badly need, or to make our users already more productive now rather than later. We deliver to eagerly waiting stakeholders, so that we do get the feedback we badly need. We don’t demo; we give it to stakeholders doing real things and observe what happens, which can be different than we expected. That’s what Shewhart already suggested when introducing the Shewhart cycle, what later was called the Deming/PDCA/PDSA/Kaizen cycle.

    As we have various stakeholders, we may have various DeliveryCycles in parallel, all with different length, as we don’t want to keep something we can deliver rotting on the table. The faster we get the feedback, the better.

  3. The true measure of an agile shop isn’t when they complete all their stories every sprint, when they slice their stories to perfectly meet INVEST, or when they have fruitful stand ups. It’s when sprints aren’t necessary, when stand ups aren’t needed, and when a mindset of continuous improvement, continuous delivery, transparency, and candid and constant communication has permeated the company’s culture. All the mechanics of scrum are simply a forcing function to help us achieve an agile mindset. When the function no longer requires forcing, you’re in a good place.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s