Join the Mastering Agility Discord community!
During the courses I teach as a Professional Scrum Trainer, as well as the reactions that I get to my articles, there’s one thing that always stands out to me: practice is vastly different than theory.
A previous article already covered Eight Things to do During the Sprint Review, this time I want to dive into Sprint Planning.
The purpose is to forecast, not to set in stone
Sprint Planning is the first event of the Sprint. The outcome of this event is the Sprint Goal and a plan for the Scrum Team to achieve it. The whole Scrum Team participates in this event.
To create a plan, three main topics are discussed:
- Why is this Sprint valuable?
-
What can be Done in this Sprint?
-
How will the forecasted work be Done?
The maximum Sprint Planning timebox for a full month’s Sprint is eight hours. For the shorter Sprints, it’s usually less. Don’t take that for an automated downscaling. For a two-week Sprint, the timebox is still eight hours, except often it just takes less time.
Quite often, the first response to the timebox is along the lines of “Woah, that’s way too much time! We’re done in an hour tops.” And then proceed without a clear Sprint Goal. Understanding why this Sprint is going to add value is the essential thing to make clear. Everything else will follow.
There is so much that can be done and discussed during this event that would save you time and context-switching later on in the Sprint, that I would like to challenge you to carefully consider the time currently consumed in this particular event. I’ll share 7 things to do during the Sprint Planning that helped my teams.
1. Use feedback coming out of the Sprint Review
Sprint Reviews are used to gather feedback from stakeholders. Too often I see feedback being suggested without any follow-up. Not taking the feedback into consideration, is not only disrespectful but also a limitation to your Scrum Team to truly deliver value.
I’m not saying you should do everything that stakeholders are saying, but it definitely should be either discussed and ordered on the Product Backlog or be rejected and have the stakeholders informed.
Discussions held during the Sprint Review can directly influence the next Sprint Planning. My current team and I have set up a specific “What’s Next” section in the Sprint Review agenda that directly influences the order of the Product Backlog to pull from in the coming Sprint Review.
2. Reassess any remaining work from the last Sprint
If there is any remaining work in the past Sprint? Do not just blindly spill it over “because it’s almost finished”, or it “needs to be done anyway”. The corporate disease TANS (There’s Always a Next Sprint) is lying just around the corning to infect you.
Any remaining work is discussed, re-estimated where needed, and taken appropriate action. That could be either that it’s being discarded if there is no value delivered by implementation anymore, it’s put back into the Product Backlog or it is indeed being forecasted for the coming Sprint. But again, don’t just spill over.
3. Use the timebox to refine Product Backlog Items
Eight hours is a really long timebox. The purpose of such a long event is to prevent too many adjustments are needed to perform the work throughout the Sprint.
If there are any PBIs that are still fuzzy and not deemed ‘ready’ for being picked up, refining those during Sprint Planning is a perfectly acceptable practice. Getting them ‘ready’ means adding details, estimates, size, and order to be able to get to Done within a single Sprint.
4. Invite Subject Matter Experts
Attendance is not limited to the Scrum Team. When it’s needed, for example, for refinement, the Scrum Team can invite SMEs to provide additional information. This could also include users, the client, or any other stakeholder. This makes the event more engaging, as well as shows you value the opinion of others.
Photo by jose aljovin on Unsplash
5. Relate the objective to Product Goals
In the book The Professional Product Owner, Ralph Jocham and Don McGreal discuss the Product Management vacuum: a disconnection between Sprint Goals, Product Goal/Product Vision, and the wider vision of the organization.
I rarely see this discussion happening, anywhere. As mentioned in the third paragraph, one of the topics to discuss is why this Sprint is valuable. In the extension of that, discuss how this Sprint is going to help us advance toward the achievement of the Product Goal and even the contribution to the company vision. This supports keeping an eye on what’s important.
It could also be the other way around: I’ve worked with a team that created a spin-off company based on innovation that didn’t meet the company vision, yet was fruitful enough to invest in. Checking in to these connections ensures a healthy organization.
6. Plan improvement items coming out of the Sprint Retrospective
As per the Scrum Guide:
The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
Make sure they indeed end up in the Sprint Backlog, else they might be overlooked or forgotten down the road. The Product Backlog (and extended to the Sprint Backlog) contains all the work for the Product. This includes improvement items as well, even if they are about the process of the team.
7. Identify dependencies (if you haven’t already)
Hopefully, dependencies are identified earlier than the Sprint Planning. But as we work in complex domains and new learnings are uncovered, new dependencies could pop up.
Make them transparent by, for instance, placing them in the description of PBIs or by creating a Dependency Board. This way you can actively work with them, instead of being reactive to them.
Bonus tips:
Use the DoD, velocity, and capacity as guidelines
Out of all possible metrics, I’d suggest starting with input like the Definition of Done, velocity, and capacity. These provide input for making a reasonably confident forecast.
The Definition of Done can be used to create a better understanding of the activities to be performed to reach a Done state. This ensures that the developers are on the same page.
Velocity provides a historical insight into the amount of work that can be completed during a Sprint. Nothing else. This can be used as a guideline to base the forecast. Make sure that velocity is not treated as any other type of hard metric or management tool.
Create breakouts
Sometimes discussions are held between just two or three people, without involving the rest of the team. The rest is zoning out, as they’re not taking part. Unengaged discussions take the energy and flow out of the meeting. This could easily be solved by creating breakout rooms when working remotely, or swarming groups when working physically together.
As a tip, I’d like to have people do some teach-back at the end of those sessions. This way everyone present knows about the conclusion of the discussion, without dropping the energy.
Take regular breaks
Especially right after the start of the pandemic, the need for regular breaks became more apparent to me than ever. Take a little break every hour, or a bit longer one every 90 minutes. While teaching classes, my rule of thumb is to take 10 minutes every hour, or half an hour after every 90 minutes. Stand up, stretch your legs, or walk outside when possible. This helps to keep the blood flowing, and therefore to be in a more creative and energetic state during the Sprint Planning.
Photo by Alessandro Bianchi on Unsplash
I’m probably missing out on a whole array of other things you could do during Sprint Planning, so I’m curious about what else you are doing in your teams. These 10 are the ones jumping to mind that would be the easiest to implement and take action on. If you have any other useful practices, help to inspire others by dropping them in the comments!