Experimenting one week sprint

Nicolas Dupont
Akeneo Labs
Published in
3 min readJan 6, 2016

In our product team using Scrum, we’ve done 2 weeks sprints during our first year building an enterprise software. Then, when we’ve released the first stable versions, we’ve changed to 3 weeks sprints to be able to handle in parallel our very new activity : support and maintenance (new story is coming).

We’ve been developing 1.5 version since 4 months with a 1 week sprint pace. We would explain why and give a quick feedback about the pros and cons encountered by using shorter iterations.

To give a bit more of context, our product team has quickly grown from 5 to 15 people and still counting. We’re experimenting a lot to find the most efficient way to scale the team and the product without loosing our accumulated good practices. The challenge for us is to keep things simple and efficient without being weighed down under a bunch of new processes and meetings.

We learn from each iteration, by doing sprint retrospectives that help us figuring out what was good, what wasn’t and what can be performed to improve ourselves. Thus, shrinking from 3 weeks to 1 week length multiply by 3 the opportunities to discuss about our problems and, obviously, to take actions. By accelerating the pace of our work, we’re speeding up both learning process and workflow experience by doing more attempts.

First, shorter iteration helped us to points out issues, each difficulty that can be endured in a longer iteration becomes a severe pain in the neck: a too long CI build, an inefficient code review, etc. It strongly pushes us to find smaller actions to remove the rocks on the road, actions should be simple enough to be applied in the next week.

Besides, it is more demanding and requires a higher predictability, we have no buffer to handle surprises, if a committed story is a bit more complex than expected, we quickly fail to complete it and have the opportunity to discuss about how to fine tune our story slicing.

In the other hand, a fallback could be to work harder to compensate for the emerging problems, this does not solve anything and only hides the issues. As we’re building and maintaining a product for years, we must take care of not being in a permanent rush state and promote a sustainable development.

Another question is that despite we have a hard time boxing, we don’t manage to reduce the time spent with our ceremonial meetings (grooming, retrospective, etc) as much as we reduce our sprint length (meaning divides by 3 in our case).

By reducing the amount of stories we engage per sprint, we also need to be vigilant about keeping a team commitment and not switching to an individual engagement per story by reducing the buffer time often used to help teammates at the end of a sprint to finish “in progress” stories.

Eventually, this shorter sprint duration also limits the amount of re-work we’re able to embed in a sprint and can quickly push us to accumulate more technical debt.

That’s it for this quick feedback, as usual, there is no magic recipe which works for every team and every context, at the end what matters is be aware of your situation, do experiments and measure progress before keeping or giving up attempts. The continuous improvement path never ends.

I publish a couple of short stories per week; about product management, software engineering, and work organization. Don’t want to miss the next one? Follow me on Twitter 🐦

--

--