Join the Mastering Agility Discord community
Dealing with uncertainty requires you to be able to pivot as new learnings and insights emerge. That’s the core of Agility; responding to change. We, as technical people, are relatively reluctant to change. I recently came across this article that very simply discusses a few factors of why we don’t like change. Because we don’t exactly know the challenges that lie ahead, we need some planning to occur in order to pave the first steps.
The Sprint Planning event is an excellent example of this. As with the other events in Scrum, Sprint Planning serves to create transparency and provide opportunities to inspect and adapt Scrum artifacts. As per the Scrum Guide:
Failure to operate any event as prescribed results in lost opportunities to inspect and adapt.
The Scrum Events need to happen at least once per Sprint. But how about more than once?
Use the timebox wisely
Consider this: Scrum Teams benefit from having at least a few Product Backlog Items (PBIs) ‘ready for development’; there’s sufficient information available to at least start working on them and the developers are relatively confident they can pull that PBI off in the Sprint.
Photo by Alvaro Reyes on Unsplash
What would happen if there isn’t enough information available after that point? Would the team just drop to the floor and lay around, waiting for work to come to them? I highly doubt it (although it sounds like a funny scenario).
A second Sprint Planning might be useful. The timebox for Sprint Planning is a maximum of eight hours, based on a full month of Sprint. It’s typically shorter for shorter Sprints, yet the timebox remains the same. If we spent four hours in the initial Sprint Planning then theoretically you’re still left with four hours for another one.
The difference with backlog refinement
“What? This sounds exactly the same as backlog refinement!” Well, yes and no. You see, backlog refinement is quite often a part of Sprint Planning. The act of backlog refinement is to add details, estimates, and order to a selection of PBIs. This way, they can be pulled into the Sprint by the Developers.
The Sprint Planning provides a discussion around three topics:
- Why is this Sprint valuable?
- What can be Done during this Sprint?
- How will the chosen work get Done?
As the first question has been discussed and clarified during the first Sprint Planning, this time around there should be no discussion. Let’s say we have a two-week Sprint, and we’re halfway through. We have already performed that has proven to be less work than we initially estimated. We now discuss what can be Done in the remaining week, and how things will get done.
Besides the getting PBIs ‘ready’ part, there’s another argument. Validation of hypotheses that are consecutive and dependent on the outcome of others, replanning might be needed. Put simpler, assume hypothesis A has an expected outcome of B or C. But while conducting an experiment to validate that assumption, it appears that we get outcome D. This wasn’t expected, therefore we need to rethink our planning that comes after the conclusion of A.
Having Sprint Planning twice could help us deal with uncertainty and the unavailability of information.
Why not shorten your Sprints?
That definitely could be an option. The length of a Sprint is based on multiple factors, including:
- The likelihood of your Sprint Goal becoming obsolete
- The ability to engage with stakeholders
- Technological availability
- Degree of complexity/levels of innovation
When it’s difficult to get (key) stakeholders on board during Sprint Reviews every week, it might make sense to have longer Sprints (leaving out the fact that it could be useful to discuss what other options you have to involve them more frequently).
Photo by Austin Distel on Unsplash
I worked with a team once that struggled to get the right people on board in single-week Sprint Reviews. Note that the Scrum Guide speaks of an Increment the minute a PBI meets the Definition of Done. They were able to continuously push small Increments to the live environments, but it was harder to gather feedback from their (key) stakeholders. They were limited in making a reasonably reliable forecast for two weeks but also limited in the ability to elicit the information they needed.
After discussing multiple options during several Sprint Retrospective, we came up with the idea to experiment with two Sprint Planning events. It worked wonders for getting more information incrementally, while still moving forward to the Sprint Goal. In fact, the ability to achieve their Sprint Goal went up that way.
We spent the same amount of time on Sprint Planning as we did before. Except now we didn’t spend that time in a single go. We used the remainder of the timebox to create more inspection and adaptation mid-Sprint.
Conclusion
Too often performing Sprint Planning events could result in a cumbersome process in your delivery of Increments. Skipping them, on the other hand, could result in a loss of focus and failure to inspect and adapt.
Technically, there is nothing stopping you from doing those twice or more when it grants you the ability to limit risk, and deliver value. As this article hopefully shows, it depends on a few elements. But nowhere does the Scrum Guide mention you can’t do it twice.
Are there any unorthodox things you’ve experienced during your Sprints that helped you deliver a ‘Done’ Increment?