6 week sprints? You’re not doing SCRUM!

I come across this quite a lot, if you’re doing more than 30 day sprints, you’re doing scrum all wrong. Whilst I agree with the sentiment of this, there are some projects where a longer sprint cycle can be beneficial – it all depends on your team structure and the work being delivered.

To set the background, for my current project, my dev team consists of;

• 1 x architect (me)
• 1 x onshore architect / team lead
• 2 x onshore developers
• 2 x offshore developers
• 1 x sharepoint architect

We’re implementing a reasonably large custom built system for our client and each piece of work is reasonably lengthy, with each epic consisting of complex UI along with substantial work to implement a workflow spine process, which would then be supported by several common sub-processes (with complimentary UIs).

Obviously we break out the sub-processes into their own backlog items, and then break the epics down into use-cases (formal stories) that could be implemented in each iteration, but we found that with 2-4 week iterations, it wasn’t possible to cut it any other way than to deliver demonstrable product every other iteration. Literally at the end of iteration A, we would be in an unfinished, unusable state, whilst half way through iteration B, we would finish that piece of work and start the next.

The reason for this is we would implement 2 or 3 of the main use cases per iteration, essentially having multiple concurrent work streams. Wrong? not in this case.

Many would argue that this was the wrong way to go about it, that we should have concentrated the entire effort in the sprint to one use case in order to complete it within the 4 week sprint, but I argue differently. Each use case is quite narrowly focussed, making it difficult for more than 2 people to work on the same use case at the same time. As such, Brookes Law applies. Too many chef’s spoil the broth – we’d have developers standing on each others toes left and right, so can’t add more resource to the use case implementation and the implementation of that one piece of work is too substantial to be delivered in a a 2-4 week iteration.

So, we broke the project down into 6 week sprints. More regimented scrum masters would argue that we aren’t doing scrum as a result of this decision, but I argue that such a comment is ridiculous. We’re still adhering to the very principles of scrum – we’re working from a backlog, we plan sprints into a sprint backlog, we deliver burn downs, we hold daily scrum meetings, we have a scrum master, a product owner, cross functional teams, regular demo’s to the business, and retrospectives – the only discernable difference is another 2 weeks on the sprint length to pragmatically cope with implementation of complex, atomic, use cases.

We’ve been running this way for 12 months now, and the results have been great. Open, honest, transparency between the project team and the business, and just as importantly, we delivered a month early. We’ve now rolled into another 6-8 months worth of work on the project and will be continuing to use this methodology.