“Agile means no planning.”
This myth is deeply rooted in our perspective on how Agile differs from a more traditional approach to work. This myth is busted. Read on to see why.
There are many myths associated with Agile frameworks. Most of which are based on misinformation and lack understanding on why an individual or group would consider moving towards an agile approach. It is critical to understand the history of agile and the frameworks associated with it before taking a stab at using agile yourself.
What does planning mean in a traditional approach?
Basically, planning is about identifying, discussing, and agreeing on the content, people, goals, resources, and timing for a given piece of work. When done in a Waterfall approach, planning is done upfront as a large effort of work to “get it right” so that when development is started, the group will only have to refer to the plan to know what to do next.
For known, unchanging, and repeatable projects this approach is ideal as it harnesses its strengths to arrive at a reasonable and straightforward plan. However, if the project faces somewhat unknown information, changing needs, and/or new conditions it may be better to use a more flexible and malleable framework. Agile may fit these needs.
What is Sprint Planning within the Scrum Framework?
Scrum is the most well-known of the Agile frameworks. Within this framework, there are 5 events, one of which is Sprint Planning. I strongly recommend that you read, or re-read, the Scrum Guide to remember the purpose and desired outcome for Sprint Planning.
“The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.” – from the Scrum Guide
This is quite different than a traditional waterfall approach where planning is done by one group that is not the same group that will be doing the work. In Scrum, this weakness is overcome by empowering those that do the work to also plan the work based on their actual experiences of doing the work.
“Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.” – from the Scrum Guide
The value of time-boxing the agile events constraints the team into having a laser-focus on achieving the purpose of the event. If there is no time-box the team will likely continue discussing and planning for a long period of time.
Sprint Planning allows the team to answer the following two questions from the Scrum Guide:
- What can be delivered in the Increment resulting from the upcoming Sprint? This allows the team and organization to use the most up-to-date information to make a common decision on the amount of work that can be completed by the team. This is critical to achieving higher predictability and to help the team rely on actual data.
- How will the work needed to deliver the Increment be achieved? This question focuses the team on determining how they will complete the work that they are committing to for this Sprint. In practical terms, the team looks at each of the Product Backlog Items (aka PBI, and usually written as User Stories) and identifies all of the tasks that need to be completed for the PBI to be considered ready for production.
Does Agile have planning? Yes. Specifically, in Scrum, planning is done at the start of each Sprint and ongoing work is done to make sure that the Product Backlog is groomed before each Sprint Planning session.
So, what if an Agile team is able to do both of these with some semblance of skill and repeatability? How can a team improve in this critical Scrum event?
Take Your Sprint Planning to the Next Level with These Tips
Below are a few simple tips that can dramatically aid your Sprint Planning to go from okay to wow! It can be useful to discuss these tips with your team and then decide together which one you will start with. And, don’t forget to reflect on the experience to see how it changed the experience and outcome of Sprint Planning.
TIP #1: Help and support the Product Owner to facilitate Sprint Planning
Often the Scrum Master is seen as the facilitator of all events and meeting – this can be helpful but not always wise. When the Product Owner assumes a more facilitative role for Sprint Planning, the Scrum Master and the team members can be free to explore, discuss, brainstorm, challenge and collaborate. And, often the Product Owner will need help to be prepared and ready for each Sprint Planning session. This can be accomplished by the Scrum Master and Product Owner to preparing a few days ahead of the event.
TIP #2: Achieve both the Sprint Goal and Sprint Backlog by the end of Sprint Planning
If at the end of Sprint Planning the team does not have a clear Sprint Goal – then they are not done. And, if at the end of Sprint Planning the team does have not a best-of-their-ability Sprint Backlog then fleshed-out then the team is not done. It is important for the team to be able to articulate the desired goal and be able to explain / visualize the work tasks that will enable them to achieve this goal. When both of these are done well, then the team has completed the Sprint Planning session. One way to keep this in the forefront of the team’s collective minds is to have a two-item checklist with these outcomes and review them at the beginning and end of each Sprint Planning event.
TIP #3: Continuously Groom Product Backlog Items to ensure that Sprint Planning is able to achieve its goals
Not all Agile or Scrum teams remember that to hold an effective Sprint Planning session requires that the work is well-known, estimated, and size appropriately for the session to be effective. The most common and most effective way to get this done is by having regular Backlog Grooming sessions to maintain the ready work list for upcoming Sprints. Many teams do Backlog Grooming once a week. However, if you feel that the team is not able to keep up with new work to be ready for Sprint Planning then it would be wise to hold Grooming sessions every two to three days until the team is caught up and comfortable.
TIP #4: Empower all team members to create their own tasks
Participation and discussion are critical for the Sprint Planning to be useful. If there are only two people speaking during the event, often the Scrum Master and Product Owner, then the Sprint Backlog will not be a collection of the wisdom of the team – it will be handicapped. Instead, find creative, unusual, and joyful ways to increase participation of all members – this may include pair discussions, writing at the same time, peer reviews, challenge each other segments of time, and rotation of speakers. Try a new approach to creating tasks during the next three sessions to increase participation. Examples include pair tasks writing, time-boxed challenges to writing X number of tasks in X time, and peer review tasks creation.
Some Closing Thoughts on Sprint Planning
Scrum is hard, that is okay. Sprint Planning is hard, that is okay too. Remember that doing Agile well takes time, patience and a team to do it with. Continue to experiment with tips and tricks, illicit feedback and ideas from your team members, and be open to learning from mistakes – this is where real learning occurs. What other tips have used with success for Sprint Planning? Share your learning and thoughts in the comments below.
I hope that each of you continues to love what you do, find more people to improve with, and move through this journey of Agile values and frameworks.
Paul J. Heidema
NOTE: Previously posted on LinkedIn on August 24, 2016Warm regards,