Why plan?
It would be great if we could predict or plan for the future so we wouldn’t be surprised. But the reality is different. Surprises force us to react unprepared, which is exhausting and error-prone. That’s why it’s important to prepare and hedge your bets.
Plan vs. reality
But how can we prepare for the future if we don’t know what will happen? As the Scrum Guide says, “In complex environments, what will happen is unknown.”. The desire to have a plan is torpedoed by the unpredictability of the future. The more time we give reality the more opportunities it can take to move away from our plan.
It is like a captain planning a voyage: He knows that he may encounter unpredictable events such as storms, currents, and other ships that force him to change course. The longer the voyage, the more likely he is to have to change his plan to reach his destination. But even if the captain has to change his plan, his destination remains the same.
Solution: Short timeframes
To keep the amount of possible changes small, it can help to keep the time frame small. In the image of our captain, this would mean planning only the way to the first stage. Appropriately, the Scrum Guide says: “They [the sprints, author’s note] are fixed-length events of one month or less, […].” Means: Plan in manageable short periods of time.
What does this mean for planning sprints?
There is a risk that we exceed the short period of a month. But should we therefore always think ahead to just one sprint? In principle, this is possible and sometimes makes sense. For example, in time-limited projects with few participants and therefore little need for coordination.
On the other hand, in the case of larger software with many participants, it often makes sense to think more long-term. For example, to coordinate areas of the company. Marketing, for example, should be given the chance to get to grips with new features at an early stage in order to prepare the market. Consulting, sales and support should also know what’s coming before customers do.
So sometimes we need to look at a timeframe larger than a sprint.
Solution: Goals instead of tasks
In order to keep the amount of possible changes small, it helps to increase the level of abstraction: You plan in less detail, much more coarsely, yet in a targeted way.
For example, if marketing knows that in a few months the bulky menu of the application will be replaced by a fancy navigation structure and which 2-3 essential features it will have, this is often already enough. Whether the menu items can also be sorted by the length of their name is less relevant.
So the plan is much coarser or more abstract than on the level of a sprint. Mike Cohn speaks here in the image of the headings of a story map of “Titles”, scaling frameworks call it “Features” or “Epics”. One can also speak of goals in OKR terms. In the image of our captain, for example, this would be the destination of his voyage. In any case, it is not something small like user stories or other content of a sprint.
Further questions from practice:
- Can there be more than one Sprint Backlog if this is a set of Product Backlog items selected for the Sprint (“The Sprint Backlog consists of […] the Product Backlog items selected for the Sprint […].”), but new Sprints always start after the previous one is completed (“A new Sprint starts immediately after the previous Sprint is completed.”)?
- How does the prio of stories in all sprint backlogs relate to the product backlog? Is the priority of items pulled into sprint backlogs higher because they are already in the sprint backlog,
or lower because items for new sprints in planning are only pulled from the product backlog? - How do we avoid overestimating when planning time frames larger than a sprint (planning fallacy)?
- How do we keep the responsibility of the developers for the sprint content (“The sprint backlog is a plan by and for the developers”), if not the team but only the product owner (pre)plans sprints?
Conclusion
“Plans are nothing; planning is everything.” (Dwight D. Eisenhower): Planning makes sense to get an overview or to pursue a goal.
Planning the future in detail on sprint level is at best a waste of time and at worst additionally damages the understanding of Scrum, the priorities and the sense of responsibility in the team.
Feedback
If you have any comments, ideas, suggestions or other feedback about this article, feel free to send me an email at Feedback[at]scrummastersmind.com.
Source: The Scrum Guide, Ken Schwaber & Jeff Sutherland, 11/22, 2020-Scrum-Guide-German.pdf (scrumguides.org) (Stand: 17.03.23)