Have you ever experienced a team that complained when you asked them to run in two-week sprints?
Many teams try to avoid short sprints (shorter than three weeks), because they don't believe they will be able to achieve anything meaningful. This has been the case with many of the teams I have worked with in the past. They all believed that two-week sprints would result in a lot of planning and no meaningful implementation.
Then suddenly I was in a situation where I had to arrange a hands-on training setup, where all the attendees were to go through an entire project life cycle in just one day. Yep -- you heard it, one day
for everything from idea to delivery. Just to make it even more "interesting," the training was to include management, the product owner (including the support team), the ScrumMaster, and the 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.
An account manager had signed a really unclear contract with a customer to deliver a "cool calculator" in a day -- and that was pretty much what the team had to work with.
Everyone got about five minutes to read the contract, and then we had liftoff.
During the day we went through the following agenda:
Envisioning (establishing the project vision and success criteria, establishing the product backlog, doing the basic architecture, and grooming the product backlog)
Sprint 1 (including sprint planning, two "daily" Scrum meetings, one grooming session, a sprint review, and a retrospective)
Sprint 2 (including sprint planning, 2 "daily" Scrum meetings, and a sprint review)
Release (including customer sign-off, project review, and celebration)
Seven and a half hours later, we were done!
Even though the day was focused on hands-on training and not optimal utilization, the teams actually did really well. Once they figured out what they needed to build, they managed to do so, to satisfy the customer, and to have fun while doing it.
The team discussing how to best implement a particular user story
So how long were our sprints? Two hours!
That included sprint planning, implementation, automated testing, continuous deployment, user acceptance tests, writing documentation, ensuring releasable software, and also conducting three Scrum meetings, one grooming session, one sprint review, and a retrospective.
The coolest thing was that the team's own initial expectations were exceeded. The team actually managed to increase velocity in Sprint 2 and would have increased it even further in Sprint 3 -- if there had been one.
Pair programming rules! And everyone does it
One 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.
The next time you hear someone complain that they only have two weeks for a sprint, you can tell them that this team completed best-practice sprints in 120 minutes -- at an increasing velocity.
If you have found this article interesting, then please don't hesitate to share the word.