Why Some Teams Almost Always Fail at Preplanning Sprints
Navigating the Fog of Beforehand
Preplanning Sprints is like navigating through a dense fog. Despite meticulous preparation, unforeseen obstacles loom just out of sight, obstructing the path forward.
Hey Peeps,
Preplanning Sprints is a recent recurring theme in some of my work and research. Given that this technique comes up repeatedly, I experimented with it to see if it could be valuable for my team.
I must confess that I approached this experiment with a hint of skepticism. My Spidey senses whispered that preplanning Sprints might contradict the core tenets of the Agile mindset.
Captivated by the prospect of improving our ability to forecast and communicate delivery dates to external teams and stakeholders, I set aside my intuition and soldiered on.
Before starting the experiment, I identified success indicators.
The process should:
Not be overly time-consuming.
Produce reasonably accurate forecasts.
Promote improved communication and transparency.
Not interfere with Sprint Planning.
Be readily understandable by others.
This writing initially detailed my quarterly planning approach, but in the interest of brevity, I'm refraining from delving into it now. If you want to learn about my quarterly planning methods, consider joining the waiting list for the upcoming course.
My initial session to preplan the Sprints for the quarter looked like this:
Set Up Sprints: Create placeholders for each Sprint in the quarter in Jira. Specify the name, start date, and end date for each Sprint.
Forecast Sprint Throughput: Utilize Monte Carlo simulation to estimate the team's capacity, determining the expected number of stories to be completed within a 14-day Sprint with an 85% confidence level.
Create User Stories: Generate user stories based on the notes from quarterly planning sessions and the team's typical work structure, covering all anticipated needs for the quarter.
Map Dependencies: Establish dependencies between user stories in Jira using the "blocks" or "is blocked by" link types to identify and manage blocking dependencies.
Obtain External Dependency Forecasts: For tasks reliant on external teams, gather estimates or forecasts regarding their expected delivery timelines to coordinate scheduling effectively.
Stack Rank Stories: Prioritize user stories based on factors such as the importance of the parent epic, dependencies, and anticipated customer value.
Allocate Stories: Assign user stories to specific Sprints based on priority, ensuring that each Sprint receives an appropriate workload. When dealing with dependencies, schedule stories in Sprints after the completion of their upstream dependencies.
This took approximately 4 hours, which included finding the optimal method for visualizing dependencies in Jira. While this timeframe didn't seem excessively time-consuming for a quarterly task, it was just the beginning.
The next hurdle emerged during the initial Sprint Planning event. As one might predict, the plan I devised with limited team input didn't align precisely with the final plan determined during Sprint Planning.
I expected this variance and didn't see it as a technique failure. Instead, I viewed preplanned sprints as a flexible projection. My aim was never to rigidly enforce adherence to the initial Sprint plans, but rather to continue to embrace the evolving nature of requirements.
The dilemma was addressing the stories initially earmarked for the first Sprint that didn't make the cut. I considered pushing them to the second Sprint, but that approach is flawed.
Pushing work items to the next Sprint could result in over-allocation. So, for each work item moved into a future Sprint, there is potentially a cascade effect of pushing lower-ranked work items into the next subsequent Sprint, which in turn may push work items out of that Sprint.
This cascade wouldn't be too complicated if the dependencies didn't further exacerbate it. For any story changing Sprints, I had to reassess its entire downstream dependency chain. This recursive process of re-evaluating more and more stories continued until I adjusted practically every product backlog item.
Each iteration of this exercise took another 1-2 hours. I adhered to this process for the first two sprints, although I began to feel I was rapidly nearing what I would consider "overly time-consuming."
By Sprint 3, we realized an overlooked dependency between epics. This revelation propelled 15 previously unscheduled work items to top priority.
And this ultimately spelled the end of the experiment. At this juncture, I couldn't rationalize the time needed for the extensive replanning effort to revamp Sprints 4-6. Moreover, I noticed a recurring pattern: this continuous reshuffling was never-ending and often labor-intensive due to our dependencies.
While I appreciated the ease of using the Sprint assignment for forecasting, my prior method proved more efficient. I could quickly estimate delivery dates by assessing the item's backlog position and our typical Sprint throughput, often achieving comparable accuracy in just 5 minutes.
In the best-case scenario, I’d spend 14 hours per quarter preplanning Sprints (4 hours initially, plus 2 hours for replanning after Sprints 1-5), totaling 840 minutes or 168 manual forecasts. Given the rarity of requests, relying on individual projections as needed is more efficient.
Beyond efficiency, I considered a more profound cost associated with this technique—some struggle to adapt to change once they've established a long-term plan. Traditional project management methods perpetuate this inflexibility. Rather than embracing change, it’s common to set a baseline and fault individuals for deviating from the plan.
"In preparing for battle, I have always found that plans are useless but planning is indispensable."
- Dwight D. Eisenhower
The sunk cost fallacy and confirmatory thinking further complicate matters. Once we establish a plan, we feel compelled to adhere to it, even if it no longer fits reality. This plan clouds our future decisions, anchoring us to past choices. We're reluctant to admit we might have been wrong and cling to the plan as if past decisions were more accurate than what we know now.
Preplanning Sprints is particularly inefficient if you have significant dependencies or frequent shifts in priorities. As a result, the process can evolve into an ongoing, time-consuming task that ultimately yields minimal value in the long run.
Some teams use this technique as a substitute for capacity planning, assuming they can commit to the workload if all stories fit into the quarter's Sprints. However, relying solely on preplanned Sprints can be unreliable, as they don't always unfold as expected. As an alternative, I've found Monte Carlo forecasting helpful for estimating the team's capacity. This approach is more efficient as it doesn't require estimating all stories upfront.
I hope my insights inspire your own experiments. If you're preplanning sprints, try pausing to assess whether the return on investment is justified. If you find preplanning valuable, share your perspective. Hearing diverse viewpoints enriches our understanding and benefits everyone involved.
Cheers,
Miranda Dulin
📖 Currently Reading
The Principles of Product Development Flow by Donald Reinertsen. There is so much to learn from this book. I’m starting to get embarrassed that it’s taking me so long to read it, but you should understand that it covers 175 principles across eight domains: economics, queuing, variability, batch-size, WIP constraints, flow control, fast feedback, and decentralization. 😮💨
🔍Vocabulary
Enhance your Agile vocabulary: Understanding new terms can unlock more effective practices and strategies.
New Blog Posts
What Emerges From Self-Organizing Teams → If you’re familiar with the Agile Manifesto, you’ll know the answer to this, but do you know why?
❤️My Favorite Things
📱 App - Snipd. With Snipd's AI, I can convert the title into a question, and the AI-generated summary extracts the answer from the snipped section. This helps immensely with my overall zettelkasten process.
🎨 Technique - Zettelkasten. I’ve been using this technique for a couple of years now and it’s really helped me think about and understand the content I’m consuming.
🎨 Technique - Evergreen Notes. Andy Matuschak’s stance on evergreen notes really helped me to solidify my own implementation of a zettelkasten.
🎬 YouTube Video - How to Study for Exams. You may not be a college student, but in the Agile space, certifications are commonly used as a way to learn new things or prove our skills. Even if you’re not on board with the certification circus, you can’t go wrong with learning how to learn.
🎨 Technique - Cornell Notes. I'm a heavy consumer of content and tend to generate copious notes. This technique aids me in organizing them for future reference. After all, if future me is revisiting notes, it’s going to be because I’m trying to find an answer to a specific question.
🎬 🎙️YouTube Video/Podcast - The Toulmin Method of Argumentation. Improve your arguments and your writing by learning how to substantiate your claims.
🎬 YouTube Video/Podcast - Just in Time Over Prioritization. The drunk agile guys would have stroked out over the idea of preplanning Sprints given their stance on just in time prioritization. I agree with most of what they say in this podcast, but determining how to implement it is another matter. It’s still worth a listen.
🎙️ Podcast - Driving Value with Sprint Goals with Maarten Dalmjin. There is so much great stuff in this podcast. The fog of beforehand, humble planning, why Sprint Goals are needed, I highly recommend this episode.
🎬 YouTube Video/Podcast - Probabilistic Forecasting Using MonteCarlo. If you’ve never heard of Monte Carlo simulation, this is a really good high level introduction.
How to Stop Counterproductive Practices and Start Delivering Value
Don't miss our actionable guides designed to help you avoid common pitfalls. Each week, we highlight a practice hindering team efficiency and propose at least four experiments to break free from its effects. Follow us on LinkedIn to ensure you never miss an opportunity to uncover better ways of working.
✍️ Quote of the Month
"Everyone has a plan until they get punched in the mouth."
Mike Tyson