Getting Lean with Weekly Sprints

by on August 18, 2011 · 4 comments

In Scrum, sprints are time-boxed delivery cycles that help keep the team focused on the goal. If you don’t know which goal I’m referring to, check out Dr. Eliyahu M. Goldratt’s novel “The Goal” (hint: I think it’s something about making money).

For web development, I run weekly sprints and this surprises a lot of people – “How can you get anything done in just one week?” Truth be told, if I could, I’d run shorten this to daily cycles, but then I think it wouldn’t be Scrum anymore (Kanban, anyone?).

You’d be amazed what you can accomplish in a week – even if it’s only to convince your team that you should try your damnedest to ship one meaningful feature every 5 days. I want to challenge the idea that longer sprints help you get more done.

Time for Development

If your sprints are longer than one week, everyone does one of two things:

  • relax because now there’s time to finish everything
  • go nuts with new requirements because the developers are so relaxed

Pretty easy to spot the deadlock here, right?

Focus, focus, focus. Don’t work on three things at once. Just pick one story, one feature, or one bug at a time. If it’s too complex to finish in one week, break it down. It doesn’t have to be pixel perfect and fully functional in the first iteration. Release it in “stealth mode”, only visible to certain users or groups (or request params).

You’d be amazed how focused the discussion becomes once you have something running on the live site. Not a design template in Photoshop, or a screenshot mashup with some ugly red markups – “This is running on the live site now?” Shit just got real.

Time for Testing

Even two week sprints allows folks to start thinking in development and test cycles. We’ll code some crap together in week one and fix the bugs in week two. Sprint complete, right?

Wrong! What usually happens – of the six features you “finished” maybe two are actually releasable. The majority go right back into the next sprint cycle (for another hack and fix-fest).

One week sprints naturally limit your optimistic tendency to try and do “everything” and instead focus on just one thing at a time. Do everyone a favor and write some automated tests for the one thing you’re working on right now. Software engineering is a lot more than just hacking something together and pushing it off to QA.

Time for Deployment

If you had a month to develop a feature, you probably wouldn’t start thinking about integration. It’s just such a long way off – and what if your feature isn’t even ready by then? So you put your nose to the grind and start coding in your own little world for a few weeks.

And, just like that, the sprint is drawing to a close! Is your code tested? No? Well, when did you plan on deploying it? What do you mean you’re having trouble finishing it!?

One of the most overlooked and yet the most critical part of any software development process, there’s no point in coding anything if it isn’t shipped. Since most people naturally procrastinate, long sprints tend to cause a traffic jam as developers frantically try and get their changes deployed before the review.

What’s your sweet spot for sprint iteration length? How’s that been working for you? Share with us in the comments below.

Did you enjoy this article? Get new articles for free by email:

Comments

  1. says

    We had been working on three week sprints owing to the fact that we had a heavy testing including performance. Ideally I agree it should be a week or at the most 2 weeks which gives that focus. Anything above that I can say we are going into waterfall in a sprint.

  2. says

    It seems that it’s been a few years since you tried this. How have your experiences been since? rnrnI’m just about to give one-week sprints a try and am curious if you stuck with it or if you fell back to the default two weeks in the end… I’d love to know!

    • says

      After doing weekly sprints for about one year, I was convinced the team finally got it. We were actually doing 2-3 releases a week! We fell back to 2-week sprints to reduce the overhead of the sprint planning and review meetings but by this was more of a formality for external departments joining us (and they were also happier to attend only twice a month).rnrnUltimately, we got the trust of the company that we were shipping and iterating very fast. Once you reach this goal, set the sprint time-boxes to something more comfortable – just don’t get comfortable about delivering!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>