Agile sprint planning meetings are held at the beginning of the sprint. During these meetings, teams decide which activities to begin. In a true Scrum environment, the activities will come from the product backlog, as prioritized by the product owner. Different teams will settle on different approaches that work for them and most agree that the goal is not to create the perfect plan. Ideally, most of the activities are aligned to the goal of the sprint. But could we find a better alternative to sprint planning meetings?
I’ve always found the Scrum approach to generally be more effective on software products, where teams are trying to build software better, faster, and cheaper than the competition does. But in my effort to spend more time thinking about how we could redefine project management so that all kinds of projects could be managed using the same approach, I’ve wondered whether the sprint planning meetings are the best way to begin a sprint.
Here are a few questions that I’m asking:
- What happens when the product backlog is really a work breakdown structure for a defined project?
- How often should we really reprioritize the activities that we decided were part of the project scope?
- What happens when the size of your team varies from sprint to sprint?
- How does changing the length of your sprint impact sprint planning meeting effectiveness?
With those questions in mind, is there a better alternative to sprint planning meetings? I would argue that Checkpoint Meetings are a better alternative. I’ll tell you why after I explain what they are and how to conduct them.
How does a Checkpoint Meeting compare to a Sprint Planning Meeting?
Proprietary to the Smart Projex methodology, Checkpoint Meetings are conducted at the beginning/end of every sprint, or time block. I frequently think of them as a combination of the sprint planning meeting and the retrospective.7 Steps to Lead Successful Checkpoint Meetings #projectmanagement #smartprojex Click To Tweet
What happens in a Checkpoint Meeting?
During these meetings, you should do seven things.
1. Focus on your endgame.
This is your chance to remind the team of why they are doing this work. As projects grow old, it can be hard to retain the enthusiasm that you started with, so take advantage of these meetings to reinforce your vision.
2. Celebrate small wins.
Review your accomplishments during the recent sprint. Celebrating small wins is a great motivational practice. When you planned the project you hopefully broke it down into manageable activities, designed to deliver something of value for the client. When activities are completed, celebrate that accomplishment! It can be as simple as a sincere shout out to your MVP during a meeting. Or schedule some down-time to do something fun with your team.
Keep in mind that in a true Scrum software project, you will be holding a sprint review at the end of every sprint to demo the feature(s) built to the client and team.
In other kinds of business projects, the activities can be done for different stakeholders. You need to determine when you are planning the project who has “sign off” authority for each activity, as it can vary. You need to figure out how you will “demo” the results of your work, as that will depend on the nature of your deliverable. Hopefully, you’ve planned your quality needs and testing requirements on each of those deliverables. That will factor into how work is delivered and approved by your client or management team.
But work hard to ensure that you have delivered results that matter at the end of each sprint and that you celebrate those small wins! That steady progress to the final goal is critical.
3. Identify and document the lessons that were learned.
Ideally, lessons learned should be tracked at the organizational level. But if that is not happening, a Google or Excel spreadsheet will work. Future teams should be able to access these lessons for maximum benefit. And in the planning process, hopefully, someone on the team reviewed previous lessons that might have applicability.
4. Review the budget against actual dollars.
The concept of a flexible execution is inconsistent with knowing when the money will be flowing in and out on a project. Thus, compromise is needed. Understanding the budget and cash flow timing on the key activities, along with appropriate management and client input, better positions the project team to execute in accordance with available cash flow.
During Checkpoint Meetings, you should seek to understand your actual costs. Keeping a close eye on the budget and the actual costs can help ensure that projects stay on track. Throwing more money at a problem, in and of itself, rarely solves the problem. Cost overruns may be a sign that scope creep is setting in. Few clients want to burn money without results.
5. Manage issues
Hopefully, you have been identifying issues during your standing meetings and resolving them quickly. But if you are coming up on a Checkpoint Meeting and there are outstanding concerns, follow up on why they haven’t been resolved. If for whatever reason, an issue cannot be resolved, enter it as a risk and manage accordingly.
6. Identify and manage risks
Identify any new risks, analyze your project risks quantitatively, and identify trigger events and mitigation strategies on your larger risks. It is essential that teams make time to identify new risks. Somehow, the importance of just thinking deeply, and brainstorming as a group, can be overlooked. Things are changing rapidly in the 21st century.
7. Plan the next batch of work
This is the key piece that resembles a sprint planning meeting. Plan the work for the next sprint. Decide which activities you will do in the next sprint and review those activities for clarity. Select a group of activities that you can ideally finish during one sprint and that will generate value for the client. Look for activities that will decrease your risks.
Remember to review what the done statement means, who is in charge, what quality looks like, etc. This is your time to get the team to buy into actually completing those activities, hopefully during the sprint. It is possible you may need to break down activities further at this point, as you continue to learn more about your project.
Whether you use the term project sponsor or product owner, someone needs to have the final say on prioritizing the next batch of work and obviously, that person needs to be at the Checkpoint meeting.
What are the best practices to use when conducting Checkpoint Meetings?
I’ve written about meeting best practices over the years and so I won’t belabor that too much. But there are two thoughts that I will discuss.
Use conflict to keep the meeting interesting.
All too often, in an effort to keep meetings to a reasonable length (not a bad thought) project leaders try to resolve all of the difficulties prior to the meeting and then use the meeting to review what has been done. But Checkpoint Meetings can be a great time to wrestle with risks, costs, lessons learned, or the next batch of work. Conflict keeps meetings from being deadly dull. So, do your preparation before the meeting and use your meeting time for those great discussions.
To mine the conflict, as Parick Lencioni calls it in his book, Death by Meeting, call on quieter people and watch body language for folks who might be holding their tongue. You want to encourage an open, honest, and robust discussion on the topics and you should expect different opinions and conflict.Checkpoint Meetings can be a great time to wrestle with risks, costs, lessons learned, or the next batch of work. Conflict keeps meetings from being deadly dull. #conflict #meetings #projectmanagement Click To Tweet
Time-block the various discussions.
There is the challenge in planning meetings to allow sufficient time for robust discussions and dissent. And to not engage in overkill. At some point, it’s time to make a decision and move on. The time block that you announce doesn’t have to be etched in stone in this case. But be reasonable.
Why are Checkpoint Meetings a better alternative to sprint planning meetings?
Like sprint planning meetings, Checkpoint Meetings are a time to focus on the upcoming work. But unlike sprint planning meetings, teams take on a lot of other tasks in a Checkpoint meeting. These other tasks can impact how you schedule the work and what you will choose to work on next. After looking at risks, lessons learned, costs, and the other details that are reviewed in Checkpoint Meetings, teams are likely to make better decisions about what work to take on next. Don’t seek perfection. No one knows what the next two weeks look like, so allow time for the unexpected.
Do you need outside help? I’m happy to hop on a call to discuss your latest challenge.