I was asked a question recently: what’s the ideal sprint length?
To start, let’s look at the purpose and function of a sprint.
The Sprint: What and Why
A sprint is a period of time in which the team promises to deliver certain functionality. At the end of the sprint, the team is supposed to deliver working product that has some new functionality (or fixed functionality). This does a couple of things.
- It provides a timeboxed expectation. The product owner/stakeholders have a reasonable expectation as to when they will be able to see something new, and it is always on the same day and time. People are creatures of habit. I always have coffee Tuesday morning with my buddy, so Tuesdays are when I automatically eschew the cuppa joe at home, and my car automatically makes its way to our usual coffee shop.
- It offers a sense of urgency and rhythm to the team. Good developers, by definition, are lazy. With an impending deadline, the desire to produce increases. Nobody wants to show up to the demo meeting and admit in front of everyone they have nothing to demo.
- It feels like progress. Progress makes everyone happy, even the tiniest, little thing. We fixed that icon that everyone was complaining about. Oh and the app doesn’t crash when you get a call.
- Most importantly, it sets up a time for feedback and pivoting. Long ago, when earbuds were something that grew in a garden, I was in charge of a project that ran for over a year. The team worked hard and produced a great product, and the client hated it. For one, they had only seen mockups on paper and never tried out the actual workflow. It is one thing to say, “okay, if I press this button, then I go to the details screen,” than to actually click the button and realize the details screen is stupid and should have never been built. Worse, the business always changes. Always. Competitors build their own app and gosh we should have “shake to pay” too, or whatever they have. And we sold our forklift shop six months ago so we don’t need any of that functionality.
Do this
The team (the people building the stuff) and the Product Owner sit down and figure out how long the sprints should be. The team will know what sort of reasonable time it will take to build and deliver a reasonable number of stories, and the Product Owner will know how often their boss will ask, “So what’s up with that thing you’re building?” so they can tell the boss that they have the latest one right here, and check out this SHAKE TO PAY feature.
Do not, for the love of all that is good and right in this world, pick 3-4 weeks, or longer, unless your stories involve mounds of concrete drying or paint peeling, because a month is too long to wait for progress, too long to discover the equipment catalog just doesn’t feel right, and offers way too many opportunities for the Boss to ask about That App Thing, and you have nothing new to show them.
Remember whatever you pick, resist the urge to change, otherwise it will mess up everything and provide little value. Once you’re feature-complete, or MVP, or come to a stopping place, then you can make a new project. If you want to reuse the backlog, you may have to repoint.
