Scrum uses a concept called a “Sprint” to eliminate the risk of complex product development and deliver value sooner to stakeholders. These Sprints are no longer than 30 days in length. If you ask anyone doing Scrum how long their Sprints are, they will usually respond “2 weeks”. If you ask them why they’re doing 2-week Sprints, you will often get a puzzled look. In order to maximize value, it is imperative to understand the significance of the sprint length to determine if the length of the Sprint is working or requires adjusting.
Why do people choose 2 weeks as a Sprint length? The two reasons I often hear are one: because that’s how we did it with our last employer. Another is because the person championing Scrum in the organization set that Sprint length. Even more interesting is when senior leadership mandated a 2-week cadence. It may seem 2 weeks is the right length, but what if things change a lot in your company? What if your customer’s needs change quickly? 2 weeks might be a long time to wait for feedback and an expensive amount of software to waste if it’s wrong.
The only rule in Scrum for Sprints is that Sprints cannot exceed one month. The Scrum Guide doesn’t say how short a Sprint can be. What if we shrunk down the size of a sprint really far, like down to 1 day? A 1-day sprint…is that ridiculous? Imagine coming into work in the morning, having a really quick sprint planning, getting to work, and by the end of the day, you have a really small increment of product. You briefly review this minor enhancement with stakeholders, then retrospect on how that day went, and repeat this all the next day. Crazy? Yeah, I know.
If you could break feature requests into tiny micro-problems that could be solved in a day or less, you would be a value-generating, risk-mitigating machine. You would have a constant stream of value delivered and your customers would love you for it. You could accept change requests constantly since you’re always at a good stopping point. The benefits are numerous.
So why doesn’t anyone actually do this? The hardest part is breaking down requirements into meaningful solutions that can be delivered quickly. Sometimes a feature request has multiple consumers that want different things, which is really like multiple features. Sometimes a customer asks you to solve a bunch of problems in their request because they thought they would get just one chance for you to work on their features. Another great tool to measure the progress made in a Sprint is the sprint burn-down chart. Read my blog about it titled: Three Dysfunctional Sprint Burn-Down Charts of Scrum Teams. Look for the small problems, the micro-problems, and create micro-solutions to start delivering value in only day-long Sprints.