Sprint Planning & 5 Useful Tips on How to Run it

Technology runs, market complexities increase and this results to the rise of interactions required by a business in order to adapt to its environmental changes. It has been multiple times explained how a better agile methodology can assist you into dealing with complexity and what are the benefits of Scrum into a business. To wrap up the components of Scrum, the framework consists of the following:

The Scrum Events is the core aspect responsible to bring all roles involved into interaction, so the Sprint gets started and Backlog items get Done in order to achieve the goal set. The former is fundamental in the agile methodology as they secure regularity and tend to eliminate the need for meetings in the middle of the process and without warning.

The Sprint Planning Meeting

3,2,1…Go! The start of this meeting is the official start of the Sprint. Scrum Master, Product Owner and the team attends to discuss WHAT will be achieved within the next Sprint and most importantly HOW. In practice, the two often bend together, but it is of high importance to have steps and goal clarified in order to have things rolling out and get your team organised, and you will typically do that by breaking your meeting in the two below parts:

1. What is the Goal of the Sprint

Whilst the overall planning is a collaborative effort between the Scrum Master – facilitator of the meeting – and the Product Owner, it’s the latter’s duty to clarify to the Development Team the most important product features that they will work on. He will be the one responsible to review, select and present the highest priority Product Backlog items and ask the team to forecast and evaluate the functionality that will be developed. It is common for this part of the meeting, to have members going back and forth to the Product Owner with clarifying questions that will drive away uncertainty, define work and effort needed to meet their sprint commitment.

Closing this part of the meeting, it’s the team’s turn to compose the sprint goal within a one-sentence description of the overall end result they target to achieve. Having this realistically defined, the questions that will follow later about depth and breadth will be answered directly considering the level that they tie directly to the goal. If the questioned work doesn’t seem related, then it needs to stay out of the sprint. Last but not least, as with all the goals set, this can be used for reporting to the stakeholders involved what the Development team is working on and what they aim to accomplish.

2. How to run the Sprint

Now imagine the team is about to attend a Relay race. The two coaches -Product Owner and Scrum Master – have accommodated the team’s training and preparation for the race by clarifying rules and strategy. They have given the team the explanation needed and it’s now the runners turn to decide how they will pass the finish line successfully with the higher score possible. It might seem a too simplistic similitude, but the HOW session consists of the following major parts: design, implementation, test and documentation activities.

The team has identified what needs to be achieved and will now start decomposing the Product Backlog items into tasks along with their estimation in duration of time. Depending on the estimations, the Development team might request some trade-offs or revision of the chosen items from the Product Owner. During this second part of the meeting, the latter must be available, but can choose to not stay in the room. This is a tact that many teams find more convenient as it gives them the freedom to discuss various implementation prospects without worrying that the Product Owner will misunderstand or judge their approach. If the Product Owner decides to stay in the room with the Development team, it will be obligatory for the Scrum Master to be in charge and keep the members focused and motivated to explore those prospects without limitation by the presence of the Product Owner. The output of this second part of the meeting will be the Sprint Backlog.

Sprint Deadline Set

Similar to the rest of the events as part of the sprint, the time allocated is fixed and usually represents the maximum duration that they need to last. The planning meeting of a common four-week sprint is usually set to last no more than 8 hours. As a general rule of thumb, the total length of the planning meeting should be the result of the number of weeks your sprint is about to last multiplied by two hours. Not a strict rule to follow, as it is common for experienced teams to finish such a planning meeting in noticeable less time than the time estimated on the Scrum Guide.

How to Prepare your Sprint

Prior to the Sprint Planning meeting, the Product Owner should:

  • Verify stakeholders’ priorities. If they have changed, it is better for him to be aware and take it into account when setting up what needs to be achieved within the next Sprint.
  • Refine the Product Backlog, a practice also known as Backlog Grooming or refinement. Having a healthy and prioritized Backlog sets the stage for the Sprint Planning. Even if it is not yet an officially accepted scrum event, many organizations nowadays consider it as a critical step that improves speed and efficiency. Why not giving it a try adapting it in your Sprint too?
  • Check the Product Roadmap, so he picks the most appropriate features to get delivered.
  • Know the Capacity but don’t fill it, be aware of everyone’s schedule for the duration of the sprint and leave some spare room for any unforeseen items that might come up.
  • Ensure the definition of ready is clear to the Development team, so you provide them clarity and create the path to deliver in a predictable way.
  • Specify Acceptance Criteria, or in other words define the conditions that a product must satisfy to be accepted by the end user, customer or system. This will set the statement with a clear pass or fail result that will be applicable at Epic, Feature and Story levels.

Important! Such a set of statements needs to be defined prior to the start of development as verifying the already built functionality will just give us the development reality instead of capturing the customers’ needs and focus to meet them.

  • Last but not least, ask the Scrum Master to review the Sprint backlog, it is one way or another your main advisor!

5 Tips on How to Run a Sprint Planning Meeting

Wrapping up the previous, we bet you have heard a lot that planning is essential to a project’s success, so we will avoid the repetition. However, you are here to explore this matter since you realize its importance, and we couldn’t do otherwise, but offer you the following 5 actionable tips and practices to follow:

1. Set a Challenging Sprint Goal!

It is of great importance to set up a goal that would be specific and measurable, as a result of the discussion between the Development team and the Product Owner. It would be a piece of cake to create a goal easy to achieve that will result into a successful Sprint, but will your team really Sprint in such a case or just jog? It is truly important to find the right balance and have a goal challenging enough to bring out the best of the team whilst keeping them engaged and motivated to deliver results.

2. Pre-plan the Sprint planning

Back to the process of getting organized, setting up a shorter meeting prior to the actual one is not a mandatory step, but it can be proved beneficial for the steps following. It is a chance to review the items that you intend to include at the next Sprint and listen to your team’s feedback. This way, prioritization, task creation and the following estimation will be much easier to complete during the actual meeting.

3. Focus on the Prioritization

There are no clear guidelines when it comes to the prioritization of tasks that will assist you reaching your goal. It is up to the Product Owner and at the next step, the team’s discretion to discuss and decide what work will be undertaken to reach the wanted results. There are teams that decide to take it easy at the start and complete the smaller tasks of their Backlog, whilst others start with the complex and leave the smaller and easier ones for the end. As mentioned before, there is no right or wrong way, as long as all members are aligned, and tasks help them fulfill the goal.

4. Don’t Hesitate to Decompose your Tasks

The goal here is to avoid having any task with estimation for completion that exceeds a full day’s work. Working on a single task for two or more days will probably leave a member behind on the progress and demotivated. Breaking a bigger task into pieces can be not only an easier goal to reach, but also a simpler canvas for collaboration with others.

5. Say no to Overload!

Whilst we want the Sprint goal to be a challenge for the team, members can easily fall into the trap of getting too confident and take an insufficient load of tasks. As a result, the work to be created will be counter-productive and there is a high chance that the team will fail to deliver the expected on-time, leading in turn into irritation and disappointment to the people involved.

Bottom line to make this whole process work for your organisation, it’s to convince the participants and stakeholders involved that the Sprint Planning is the most important meeting that they need to conduct. Pushbacks and demotivation will not lead to effective planning, so to make it work, you will need to ensure the importance of it is clearly communicated to everyone. It will lastly be the Scrum Master’s responsibility to create an experience out of it and persuade the team that this is an advantageous process to be engaged to. At the end of the day, optimising the basics of Scrum will be the base to explore its mastery.