In Agile Sprint Planning, Less Is More
Overview: Packing an Agile sprint with a list of to-do’s doesn’t mean you’re going to get more done. It’s often true doing less actually helps you produce more. Keep reading to learn why.
Here in Detroit, there’s a neighborhood called Lafayette Park designed by famed architect Ludwig Mies van der Rohe. Mies’ architectural aesthetic was one of “less is more,” a minimalist approach that valued reducing the design of his structures to only their essential elements.
In Agile Development, a similar approach should be applied to your two-week sprints. If you’re faced with sprint after sprint of leftover items that were included with good intentions—stories that were really, really needed so you just had to have them there even though you knew they wouldn’t happen—you’re setting up your team for failure.
While you may believe that putting more into your sprint will accomplish well, more, you will find that you actually get less. By setting up your sprints with what feels to be less, you will actually accomplish more.
Take it from Mies van der Rohe that less is more—and take it from us, too. Here’s our experience in using that approach with sprint planning.
Matt’s Experience as a Scrum Master
In Scrum, an Agile framework we use, taking a “less is more” approach is an encouragement for us to be more realistic with ourselves when it comes to sprint planning. There can be a lot of pressures on the team to push and get as much done as they can. While this can be a good thing at times, it is detrimental if it leads the team to try to take on more than they can handle.
This can lead to a disappointing sprint review where either not everything was completed or even less was accomplished than might otherwise have been with a little more focus. When someone feels rushed to do something they are also more prone to making mistakes or overlooking details.
We need to be realistic during sprint planning and only bring in tasks that we believe can get done. If there is any uncertainty or you are working with a team that is still honing their estimation skills, it is always better to err on the side of “less is more.” This way, you are more likely to find at the end of the sprint that everything was completed.
This will lead to a more positive sprint review, and if you find that certain tasks were done more quickly than expected you can always pull from the backlog to fill remaining time or even take care of some technical debt.
Mark’s Experience as a Product Manager
Each sprint planning session, I have to remind myself that less truly is more. Maybe it’s a bad habit from my pre-Agile Waterfall days, but I sometimes have the urge to cram more into a sprint with the illusion that my team could actually get it accomplished.
Fortunately, from experience I’ve learned to be honest and really strip things down to the essentials with Agile stories that can be accomplished within a two-week sprint. I’ve learned that just putting something into a sprint won’t make it happen.
You also have to account for snags that can occur. If you’re trying to cram everything you can into a sprint, you don’t leave any room to take care of these snags. Maybe you end up pushing through but what you produce isn’t of the greatest quality—now you’re just creating technical debt because you’re only focusing on throughput.
With “less is more,” when things go well, developers can pick up a bug from the top of the backlog or a story from the next sprint, as Matt noted. Of course, it’s worth noting this means you have to have your bugs prioritized as well as have the items in the next sprint prioritized and sized.
Setting up the proper sprint cadence will take some discipline, but by sticking to a “less is more” approach, you will see the effects soon with increased throughput and greater pride and confidence in your team.