1 Week Sprints

I've tried to avoid 1 week Sprints.  Move to Agile/Scrum was challenging at first, and 2 week Sprints seemed the minimum amount of time for the mini-project lifecycle that occurs within each one.  However, I now have a client that needs the work completed in less than 8 weeks, which means less than 4 Sprints.  In my experience, you can't succeed with less than 4 Sprints. 

What to do?  Typically, I revert to waterfall for projects this short: a single, long Sprint.


However, that assumes you have buttoned-down design up front.  In this case - developing an intranet - we don't have that.  The design of the web site will be heavily influenced by feedback throughout the development process.


So we are going to 1 week Sprints, with only 1 Developer and 1 Designer.  This will give the Customer more than 4 reviews during which feedback can be provided.


We are just starting Sprint 3 and here's what I've learned so far:

• Yikes - this is fast!  It forces a daily deployment cadence - not something we're used to.  We can't wait until Day 3 to start testing - the Developer won't get the defects until the Sprint is almost shot.  Daily deployment is an adjustment for us - I'm curious to see how it goes.
• My Sprint burndown! - my beautiful Sprint burndown!  It doesn't ever really burndown any more.  We have stories that have tasks for both the Designer and the Developer.  The Designer has to get done first.  If he starts his tasks on day 4 of the Sprint, the Developer doesn't stand a chance of getting his part done in the current Sprint.  This means that a number of User Stories are left incomplete at the end of the Sprint.  That's not a problem, because we simply push them forward into the new Sprint.  First Sprint you do this in your velocity takes a hit, but then it washes out going forward.  But the Sprint burndown doesn't reach zero hours any more.  Oh well, at least the Release Burndown still makes sense.
• Customer visibility = check.  The Customer is seeing things much more often - and this is a good thing.  In fact, it is the point of the adjustment to 1 week Sprints.
• Constant Pressure.  There is no slack time in the Sprint.  It's not the same as a death march, which typically implies working nights and weekends, with quality being jettisoned.  Rather, there is simply no time to lose, no time to waste.  This maximizes personal accountability for everyone involved - even the Project Manager!  The finish line is in full sight the moment the Sprint starts.

Here are a couple of good, quick reads on the subject:

• Choosing the right Sprint length
• Choosing a Sprint length - Shorter Trumps longer (with helpful diagram)

How about you?  Have you done 1 week sprints before?

Sprints - How few is too few?

I believe firmly that there are a minimum number of Sprints necessary for Agile to work

That's right, any less than 4 Sprints and you won't get the Customer feedback you need.  Think about this:

• Sprint 1 Review: Typically this is a barebones presentation.  The product (website etc.) doesn't look like much yet, and the Customer generally says, "Great - glad to know we're progressing." 
• Sprint 2 Review: Okay, now there's something to see and the feedback starts coming in.
• Sprint 3 Review: More to see = more feedback. 
• Sprint 4 Review: You're done.  UAT ("hardening") may follow and will produce feedback, but it should be tweaking the product, not continuing to design it.

So that's 2 touchpoints for the Customer.  That is barely useful - you run the risk of the Customer saying at the end of Sprint 3: "Wait a minute!  You're telling me that we only have 1 Sprint left and it's almost full already? - I barely got to provide any input!  This product isn't even close to being ready."
You are now in a sticky situation.
Even with 4 Sprints.
So what do you do if the project won't sustain 4 or more Sprints?

1. Reduce the Sprint duration.  E.g. from 2 weeks to 1 week.  That will allow you to double the number of Sprints without affecting budget or schedule.
2. Don't use Sprints.  The project may be short enough that you can do all of the design up front and just have a single development/test cycle.  In other words, don't use Scrum.

Note that I didn't say, "Don't use Agile."  You could still use a Backlog, a Task Board, a Burndown chart etc - in fact, we typically do in these situations.  In fact, you could shift to Kanban. 

Have you had to deal with adapting Agile to smaller projects like this?  How have you handled it?