Effective Sprint Planning

Sprint Planning is the most crucial event of Scrum Framework. By outlining the work to be completed during the Sprint, Sprint Planning kicks off the Sprint. The collective efforts of the whole Scrum Team go towards creating the final plan.

The Product Owner makes sure everyone is ready to address the most crucial things on the Product Backlog and how they relate to the Product Goal. To get input, the Scrum Team may also invite other persons to Sprint Planning. In Sprint Planning, the agenda should be to discuss why, what and how parts. i.e. 

Why is Sprint valuable? (Sprint Goal)

What can be Done in this Sprint? (Prioritized Product Backlog Items)

How will the chosen work get done? (Tentative Plan to deliver value)

For a one-month Sprint, Sprint Planning is timeboxed to a maximum of eight hours. The event is often shorter for shorter Sprints.

Developers also must identify the dependencies and highlight them in the Sprint planning meeting so that it becomes transparent to everyone.

All Scrum Team members know the state of the current Increment. Having the Definition of Done in place and discussing it in the Sprint Planning helps to create a better understanding of the activities to be performed to reach a Done state so that the Definition of Done brings transparency among all the team members. Definition of Done (DoD) could drive items to be picked up basis what all things need to be done in each product backlog item.

The Scrum Team also might have identified improvement points from their last Sprint Retrospective and might have created a plan for the improvement item(s). As a result, they will likely improve their team effectiveness and Sprint planning is a good opportunity to discuss these points as well.

Importance of Sprint’s goal

Finding the value of the upcoming Sprint is the most crucial part of the Sprint Planning event.  The Sprint Goal is referenced in this “why” for the Sprint.  The Sprint Goal outlines the total benefit that Sprint will bring to the Product goal.  

I’ve spoken with a lot of Scrum Teams that don’t always define goals for each Sprint.  They are losing out on the team’s increased attention as a result of this activity.  

Consider a Scrum Team plans to pick up a few Product Backlog Items.  During the middle of the sprint, they realize that they won’t be able to deliver all of them. They will have to narrow the scope of the Sprint. However, which PBIs ought to be prioritised above others?  Making a choice is challenging without having a clear Sprint Goal

Furthermore, the Sprint Goal acknowledges that we cannot know or forecast what will occur during the Sprint due to the complexity of the environment.  Because of this, the Scrum Team commits to producing a Done increment that satisfies the Sprint Goal rather than the specific PBIs they decided upon during Sprint Planning.  It’s a little but significant distinction.  

The Product Owner will work with the Developers to decide which PBI to drop from Sprint if things don’t go according to plan, giving the team the best opportunity of delivering a Done increment that satisfies the Sprint Goal.

Flexible plan of value delivery:

The Scrum Team should talk about how they intend to deliver the Product Backlog Items they chose for the Sprint during Sprint Planning.  They don’t have to go into minute detail about each day’s activities, but they should have enough of a plan to get started, leaving the remaining details to come to them during the Sprint.  To reduce the waste that comes with bottlenecks or dependencies or impediments, planning can also identify any dependencies among Scrum Team members and how to address them.   For instance, if Sprint is focused on planning a party, it is necessary to decide who would choose the menu, decide Guest list and purchase the items. By doing this, duplication is prevented, saving us from having to send five people to the shop to purchase the items. A little planning will help to make sure the team uses their time well. The team receives insightful input to improve work processes as each team member discusses how they intend to complete the work.

Estimation of work- is it required in Sprint planning?

As per Scrum Guide, the Estimation process is not part of the Scrum Framework. Many Scrum Masters make an estimation of the work item (story points, Tshirt Sizing, Hours), velocity and capacity all mandatory as a part of Sprint planning. Remember, these are all complementary Agile Practices. There is no mention of Estimation, Velocity or story points in the Scrum Guide. Don’t force your teams to estimate work. Give them autonomy to pick how many can they do that align with Sprint Goal. Your velocity or story points should not dictate the team in picking up work.

Outcomes of Sprint Planning

The only Outcomes of Sprint planning are Sprint Goal and Sprint backlog. The developers along with Product Owner crafts the sprint goal before the end of the Sprint planning and identify the Sprint backlog. Apart from these two things, it doesn’t matter whether they estimate the work or not, whether they have all the details of the work items. They should have enough details to start work on the and have identified Sprint backlog items by the end of the Sprint Planning

For new Scrum masters, whenever you are helping teams implement Scrum, remember your purpose of doing Scrum is not getting Scrum right but to help the business grow and serve customers to achieve goals/solve problems.

So teach your teams to have their goals solid. Your entire sprinting should be around Product goal(s) and Sprint goals. The goal should drive your plans and not vice versa.

Let me give you an example, Imagine, you are planning for a vacation or a holiday, you decide your destination (goal) first and then prepare an itinerary or plan.
Now, you decide your destination and you have your itinerary/plan and you are on your road trip. Suddenly your car gets punctured, or you find heavy traffic on a route, and you don’t go back home saying that your plan is not working out. In this case, you either fix your car and move ahead or take an alternative route and go ahead with your destination.
This means you still stick to your goal but are flexible on plans

The same things you have to teach your teams as Scrum Masters. Be rigid (for lack of a better word) on your goals and flexible with your plan.

Conclusion

Beyond deciding which PBIs the team will produce during the forthcoming Sprint; the Sprint Planning event has other goals.  The Scrum Team must utilise Sprint Planning to create a Sprint Goal that explains the importance of the Sprint.  The debate should also cover a broad strategy for implementing the chosen Product Backlog Items.  By including these elements, the team becomes more efficient and their attention rises. Delivering a Done increment that fulfils the Sprint target every Sprint is more likely when all three of these planning areas are combined.

Along with this, Sprint Planning could also cover how this Sprint would assist us to progress in achieving the Product Goal and even how it will contribute to the company’s goal. This encourages maintaining focus on what matters.