Is it OK to plan several Sprints in advance?
07/14/20 • 5 min
In this episode, Professional Scrum Trainer Sam Falco answers the question: "Is it OK to plan several Sprints in advance?"
I’ve seen this practice in many organizations. Product Owners plan four, five, even six Sprints of work for their teams. The result is something like a Gantt chart with Sprints instead of weeks as the unit of measure. It’s a bad practice with many drawbacks and no real benefit.
It diminishes transparencyThe Scrum Guide’s description of the Product Backlog gives us our first clues that planning Sprints in advance is a bad practice.
- “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.”
Assigning Product Backlog items to future Sprints means that you’re splitting your Product Backlog into multiple lists. The order is more difficult to see, and instead of a single source of requirements, you now have several.
The Scrum Guide also says that the Product Backlog is dynamic and constantly changing. Having Product Backlog Items scattered over a number of Sprints makes managing this dynamic change more difficult than if you have a single artifact. In one organization I was in, Product Owners would plan an entire Program Increment and then spent a significant amount of time trying to manage multiple forecasted Sprint Backlogs as well as the remaining Product Backlog.
It diminishes self-organizationWhen multiple Sprints are planned in advance, the Development Team loses its role in collaborating with the Product Owner to craft a Sprint Goal and select Product Backlog Items into the Sprint Backlog that they believe will help achieve that Sprint Goal. Often, no Sprint Goal is identified—instead, the goal is for the Development Team to “do all the things.” The Development Team’s autonomy is hobbled, and it is robbed of the opportunity to self-organize around a coherent, meaningful goal.
It diminishes inspection and adaptationThe Scrum Guide closes its definition of the Product Backlog by pointing out that while forecasting progress may prove useful, forecasting techniques “do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.”
Planning multiple Sprints in advance means that we are making decisions about the future based on what we expect will happen. Sprint six is planned based on what we expect to do in sprints one through five, for example. We’re making assumptions about the future before we have a chance to validate what we’re doing right now. It tends to result in attempting to produce to a forecast rather than basing our work on current business conditions.
But how do I forecast?Proponents of planning multiple Sprints in advance say that they need to do it in order to forecast release dates. But as Scrum Master Yoda said, “Always in motion is the future.” Planning several Sprints at a time, only to have to re-plan them as things change is wasteful and doesn’t create certainty.
Instead, we should embrace uncertainty and incorporate it into our forecasts, providing a target range that widens the farther out we look.
Forecasting with Scrum is best done by understanding our team’s velocity (as it actually is, not as we want it to be). We can use what we know about the team’s historical ability to deliver to make a “good enough” estimate of the least and most they are likely to produce.
Want to Learn More or Get in Touch?Register for our upcoming web meetings by visiting agilethought.com/events
See available training courses at agilethought.com/training.
Visit the website and catch up with all the episodes at AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
In this episode, Professional Scrum Trainer Sam Falco answers the question: "Is it OK to plan several Sprints in advance?"
I’ve seen this practice in many organizations. Product Owners plan four, five, even six Sprints of work for their teams. The result is something like a Gantt chart with Sprints instead of weeks as the unit of measure. It’s a bad practice with many drawbacks and no real benefit.
It diminishes transparencyThe Scrum Guide’s description of the Product Backlog gives us our first clues that planning Sprints in advance is a bad practice.
- “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.”
Assigning Product Backlog items to future Sprints means that you’re splitting your Product Backlog into multiple lists. The order is more difficult to see, and instead of a single source of requirements, you now have several.
The Scrum Guide also says that the Product Backlog is dynamic and constantly changing. Having Product Backlog Items scattered over a number of Sprints makes managing this dynamic change more difficult than if you have a single artifact. In one organization I was in, Product Owners would plan an entire Program Increment and then spent a significant amount of time trying to manage multiple forecasted Sprint Backlogs as well as the remaining Product Backlog.
It diminishes self-organizationWhen multiple Sprints are planned in advance, the Development Team loses its role in collaborating with the Product Owner to craft a Sprint Goal and select Product Backlog Items into the Sprint Backlog that they believe will help achieve that Sprint Goal. Often, no Sprint Goal is identified—instead, the goal is for the Development Team to “do all the things.” The Development Team’s autonomy is hobbled, and it is robbed of the opportunity to self-organize around a coherent, meaningful goal.
It diminishes inspection and adaptationThe Scrum Guide closes its definition of the Product Backlog by pointing out that while forecasting progress may prove useful, forecasting techniques “do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.”
Planning multiple Sprints in advance means that we are making decisions about the future based on what we expect will happen. Sprint six is planned based on what we expect to do in sprints one through five, for example. We’re making assumptions about the future before we have a chance to validate what we’re doing right now. It tends to result in attempting to produce to a forecast rather than basing our work on current business conditions.
But how do I forecast?Proponents of planning multiple Sprints in advance say that they need to do it in order to forecast release dates. But as Scrum Master Yoda said, “Always in motion is the future.” Planning several Sprints at a time, only to have to re-plan them as things change is wasteful and doesn’t create certainty.
Instead, we should embrace uncertainty and incorporate it into our forecasts, providing a target range that widens the farther out we look.
Forecasting with Scrum is best done by understanding our team’s velocity (as it actually is, not as we want it to be). We can use what we know about the team’s historical ability to deliver to make a “good enough” estimate of the least and most they are likely to produce.
Want to Learn More or Get in Touch?Register for our upcoming web meetings by visiting agilethought.com/events
See available training courses at agilethought.com/training.
Visit the website and catch up with all the episodes at AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
Previous Episode
Intent-Based Leadership with Michael Guiler
This week on the Agile Coaches’ Corner, Dan Neumann is joined by a new guest, Michael Guiler! Mike is an Agile Consultant at AgileThought. He has been an Agile coach for over 13 years now and has tons of experience helping geographically dispersed organizations (both business and technology) transform to better achieve their goals. His focus is on helping organizations learn and apply the values and principles of the Agile mindset to continuously improve.
In this episode, Dan and Mike will be focusing on the topic of intent-based leadership and the key leadership characteristics that allow for intent-based leadership. Mike shares how an organization can begin to take the first steps towards intent-based leadership, how to avoid common pitfalls, and shares his best practical tips and advice on embracing intent-based leadership throughout the organization.
Key Takeaways
What is intent-based leadership? What problems does it solve?
Helps to get the entire team to chip in and no longer wait for approvals and sign-offs
Takes the pressure off of one single leader and unlocks the potential of every employee
The opposite of directive leadership
Changing the pattern from leader-follower to leader-leader
Those in the leadership level are not telling people what to do/how to do it; they are setting goals and directions
The ‘followers’ are engaging their creativity, mind, and intelligence and leveraging those skills and sharing their solutions with the leadership (this gives the organization a great opportunity to learn and exposes leaders to things they hadn’t thought about before)
Getting started with intent-based leadership/Characteristics of leadership to allow for intent-based leadership:
Before the leader-leader pattern can take place a lot of growth has to take place
Keep in mind that this process won’t happen overnight
Immediately begin to address competence — leadership at all levels can’t thrive if your team doesn’t have the skills or knowledge to prioritize and take action
Establish safety — mistakes will happen; it’s how we react to those mistakes that will enable leadership at all levels to thrive or to fail miserably
Use mistakes as a learning opportunity rather than punishing an individual
Be curious and ask good questions from a place of true curiosity
Challenge your preconceived notions of how things have always been done
Embrace new ideas and thoughts — there’s a real chance you’ll learn something!
Allow time for the team to talk out loud
Respect others opinions and encourage others to have their own point of view
It’s hard and will take a lot of time and investment (but it’s money well-spent — the productivity will explode)
It’s important to set guide rails in the technology world
Focus on the goal/outcome instead of the ‘how’; set clear intentions and let the team figure out how
Adopt the “I intend to” language pattern
Mike’s intent-based leadership tips:
Once the competency is established and you’ve gotten your organization thinking about it, it is important to establish safety (without safety people won’t bring their creative-selves or do anything new)
It is key crucial for the team to know what the goals are
Have an “ish” mindset; decisions and actions being taken won’t match yours and that’s OK!
Overcome urges to command and control
Be tolerant of differences and encourage different points of view
Mike’s recommendation to further learn about intent-based leadership:
Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet
Mentioned in this Episode:
Agile Coaches’ Corner Ep. 84: “Getting to ‘Finish’ as a Scrum Team with Andrea Floyd”
Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet
Forbes article regarding psychopathology in CEOs
Michael Guiler’s Book Picks:
The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning
Next Episode
Agility: Not Just an ‘IT Thing’ with Andrea Floyd
In today’s episode, Dan Neumann is joined by return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought. Andrea has 25 years of experience in software development and management. She is an innovator who has led multiple organization-wide scaled agile implementations, and she has also architected innovative solution strategies and roadmaps across many frameworks (including Scrum, Kanban, and the Scaled Agile Framework).
Dan and Andrea will be discussing the premise of agility and the common misunderstanding that it is only an IT ‘thing’ and is software-centric. Andrea explains how agility addresses needs across the enterprise and that it is about collaboration with many different areas of the business beyond IT. She shares how a shift from software agility to business agility drives the enterprise; and talks collaboration, feedback loops, design-thinking techniques, the importance of being customer-centric, applying agility across the organization, and key considerations around bringing the technology side and business side together.
Key Takeaways
Considerations when shifting to a more business agility:
Be careful not to create “us vs. them” scenarios (‘us’ as in the technology side and the ‘them’ being the business side)
As leaders, it is important to open up about the way you think about Agility and the principles
It is important to create a united effort of working together to achieve the desired outcomes (moving from ‘doing’ to ‘understanding’)
Be aware of cognitive biases, for instance, the ingroup and outgroup bias (where people tend to ascribe positive behaviors/attributes to people they consider to be in their group vs. ascribing/amplifying negative behaviors/attributes to people they consider to be outside of their group)
It is important to expand your ingroup bubble to at least your whole company (which would lead to more interpretation of positive intent and better collaboration)
It’s not about the individual developer getting to done; it’s about the team getting to done
Being more inclusive and valuing what every individual is bringing to the table has an incredibly profound impact
Key pieces in shifting from a software (or IT-centric) view of agility to business agility:
Start to reimagine roles and how you operate together
The business side needs to welcome the technologists to their side/domain and vice versa
Everyone needs to understand that there is huge value in understanding their customers/users and understanding the ‘why’ behind delivering
Allow people to be free and feel safe enough to create and innovate
Invite everyone into the full conversation
Truly value being engaged
Work towards building empathy between the people building the software and the people who will be using it
Apply the Agile principles, practices, and mindset pieces across the organization
Understand the ‘why’ behind why you’re doing agile practices as well as the intention behind them
Key places to have dynamic conversations with technology and the business:
Through backlog refinement — the inclusiveness comes from the product owner being able to articulate
Come up with a more creative ‘how’ or an ‘incremental how’
The product owner can communicate “no” or “not yet” to their stakeholders
The software on its own is not the product; there are other key pieces that create the ‘shrink-wrapped’ product
“When we think about business agility, what we want to do is understand what it takes to really get that product into the hands of our customers”
How you coordinate across the teams so you get that “shrinkwrapped product increment” is important
Think beyond just getting the software to ‘done’
Key points around accelerating the value chain:
Look to make ‘idea to value’ as short of a line as possible
Reference The Age of Agile’s three laws of business agility: the law of the customer, the law of a small team, and the law of the network
Empower your team and allow for autonomy
Feedback loops with your users/customers are key
Design thinking techniques are a great way to learn more about your customers/users
Empathy is huge — it is the basis for innovation and creativity
Mentioned in this Episode:
Modern Agile — Joshua Kerievsky
The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning
If you like this episode you’ll love
Episode Comments
Generate a badge
Get a badge for your website that links back to this episode
<a href="https://goodpods.com/podcasts/agile-coaches-corner-111882/is-it-ok-to-plan-several-sprints-in-advance-5749089"> <img src="https://storage.googleapis.com/goodpods-images-bucket/badges/generic-badge-1.svg" alt="listen to is it ok to plan several sprints in advance? on goodpods" style="width: 225px" /> </a>
Copy