Before you start reading this post, I want to make you aware that it is part of a series on Sprint Planning for Agile Marketing teams. Here are some of the post in this series:
- This Post - Put On Your Game Face - The Basics of Sprint Planning
- Some Assembly Required - The Tools
- Content Developers, Cross-Functional Teams, and Commitment
- Breaking Down The Tasks
- Go Run! Starting a Sprint
- How do I End My Sprints Well?
- What Do I Do When Things Go Wrong?!
One of my favorite parts of teaching Agile Marketing to a team is the first Sprint Planning Session. I love the pressure release that occurs when the team commits to producing this particular set of content at a sustainable pace and they can get to the business of Content Marketing. I get excited when I witness the teamwork that goes into breaking Content Items down into Tasks and seeing how they work on them with more autonomous assignments. And I’ll admit that I get a little emotional when I see the team lead or Content Owner demonstrate their trust in the process and place faith in the team to deliver.
Sprint Planning is one of the final stages in executing on a full Agile Marketing Strategy for your team. Up to this point you should have developed Personas, a Content Mission Statement, assigned roles for your team, created a prioritized Content Backlog, and estimated your Content Items. Each step helps build on to the next, but you can slow down and make sure you have a good grip of the process at any point along the way. After Sprint Planning, you are now ready to create content.
In this article, I will cover the basics of Sprint Planning and what to expect when you get started.
Fundamentals of Sprint Planning
To get started with Sprint Planning, we need to determine the length of the Sprint. Some teams decide they would like the duration to be one-week, others prefer upwards of four weeks. I am a fan of the three-week Sprint as it gives you a week to ramp up, one for really digging in, and the last week for wrapping up.
Once we have the duration, your ScrumMaster needs to schedule a Sprint Planning Meeting with the Content Developers and the Content Owner.
Next, the ScrumMaster will determine the availability of the Content Developers over a selected duration. Remember to account for Paid-Time-Off, holidays, and any other whole team corporate activities.
Since I estimate with Ideal Days during our Planning Poker session rather than applying the current chaos to the situation, I bring in a percentage of efficiency, starting at 70%, to apply to the actual availability. This gives us a common reality we can expect and a more accurate estimate for available resources.
Ideal Days use the concept of estimating without usual work distractions in place and then applying the distractions back into your planning at the Sprint to better match current reality.
With the total number of resource days available, sometimes referred to as points, we can hold the Sprint Planning Meeting.
To kick off the meeting, your team will select the Content Items with the highest priority determined by the Content Owner that fit inside the points available. Then each Content Item will be discussed to determine the quality and value delivery. Once we understand the expectations, the team will create the Tasks associated with the Content Item and assign an estimate.
A Scrum Board will be used to place these tasks and Content Items on. This board will be in a physical location using paper or with a digital system. We will get into that later in this series.
Place all the Content Items and tasks in the Open Column and answer any final questions. If you plan to start your Sprint after the meeting, hold your first Standup Meeting before you dismiss.
Calculating Meeting Length
Once you are ready, select a date, pick a room, and give yourself about one hour for every week in your Sprint and one hour for every four Content Developers. This calculation will change once you learn more about your team’s rhythm, but it seems to work pretty well to get started.
Example (two-week Sprint, two Content Developers): 15 minutes * 2 developers * 2 weeks = one hour Sprint Planning Meeting
Get the Meetings on the Calendar Early
This meeting will become a tradition of your team and everyone involved will expect the timing. But, we all participate in outside meetings and get pulled in several directions during the day. The agile process will start to isolate the Content Developers from this dilemma but the more detached you are from the creation of content, the greater chance you spend a significant part of your time in meetings.
Once we have the date of the first day of the Sprint, we can quickly determine the last day and the best day for the Review, Retrospective, and Sprint Planning. These may span a couple days depending on your team size and availability. However, the closer they are to each other, the better chance we have to get the next Sprint kicked off promptly.
I start with what works for the Content Owner. Their schedule tends to be the most hectic and they are not required to attend the whole meeting. If your previous Sprint is ending, get the Sprint Review and Demo scheduled first as they are the target audience for this meeting.
Next find a time that works for everyone to plan the next Sprint. You might block out some extra time at the end if you are just getting started to allow for overflow. But remember, just because the meeting is on the books, it does not mean we have to use all of the time allotted for the meeting.
Finally, get the Retrospective on the Content Developers calendar. You can do this meeting outside of the office over lunch or near the end of the day when all other planning has been complete. Having the Retrospective Meeting after the Sprint Review and the next Sprint Planning meeting can be of benefit to resolve any issues with planning, but over time you might find it works better in-between. If estimating or performance is the problem your team needs to address, have the Retrospective before your Planning Meeting. If your team is moving forward well and you find the meeting has minimal discussions, put it afterward and allow for more time to reflect on the whole process more than the big issues.