Rennebo

Have you ever experienced a team that complained when you asked them to run in 2 week Sprints?

Many teams try to avoid short Sprints (shorter than 3 weeks), because they don’t believe they will be able to achieve anything meaningful.

This has also been the case with many of the teams I have worked with in the past. They all believed that 2 week sprints would result in a lot of planning and no meaningful implementation.

I was then suddenly in the situation where I had to arrange a hands-on training setup, where all the attendees were to go through an entire project lifecycle in just 1 day. Yep – you heard it – ONE DAY for everything from idea to delivery. Just to make it even more “interesting”, the training should include Management, Product Owner (incl. Support Team), Scrum Master and Team – a total of 16 people.

Ok – I’ll be honest. It was a challenge to plan the training session, but after a Dry Run, we were ready to “rock’n’roll”.

The set up
An account manager had signed a really unclear contract with a customer to deliver a “Cool calculater” in a day – and that was pretty much what the team had to work with.

Everyone got about 5 minutes to read the contract, and we had lift-off.

During the day we went through the following agenda:

Brief introduction
Envisioning (incl. establishing the project vision, Success Criterias, establishing the Product Backlog, doing the basic architecture and Product Backlog grooming)
Sprint 1 (incl. Sprint Planning, 2 “Daily” Scrum Meetings, 1 Grooming Session, Sprint Review and Retrospective)
Sprint 2 (incl. Sprint Planning, 2 “Daily” Scrum Meetings, Sprint Review)
Release (incl. Customer sign-off, Project Review and celebration)
7,5 hours later we were done!

The accomplishments
Even though the day was focused on hands on training and not optimal utalization, the teams actually did really well. Once the team had figured out what they needed to build, they managed to do so, satisfy the customer and have fun while doing it.

So how long were our Sprints? 2 hours!
(and that included Sprint planning, Implementation, automated testing, continious deployment, user accept tests, writing documentation, ensuring releasable software, conducting 3 Scrum meetings, 1 Grooming session, 1 Sprint review and a retrospective)

The coolest thing was that the teams own initial expectations were exceeded. The team actually managed to increased velocity in Sprint 2, and would have increased it even further in Sprint 3 (if there had been one).

Conclusion
1 custom built product delivered to a happy customer on a USB stick in 7,5 hours – and the team had fun doing it!

I have now helped several teams repeat the success, and I bet you can do it as well.

Next time you hear someone complain that they only have 2 week for a Sprint, you can just tell them that this team completed best practise sprints in 120 minutes – at an increasing velocity