What is a Sprint Retrospective and How to Run it?

Technology runs, market complexities increase and so does the number of interactions required by a business that wants to adapt to its environmental changes. Many times it was explained how agile methodology can assist you when dealing with complexity and what are the benefits of Scrum for modern teams. 

To wrap it up, the Scrum framework consists of the following components:

• The three roles: Scrum Master, Product Owner, and the Scrum Team Member
  
• The Backlog
  
• Sprints
  
• The four Scrum Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

The four Scrum Events are responsible for facilitating interaction between all roles involved. These events are 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 is the launching pad for all the other events as it launches the Sprint with Backlog items that need to get Done to achieve project goals.

Let’s dive deep into how Sprint Planning works and cover what it takes to set off a perfect Sprint for your agile team.

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 attend to discuss WHAT will be achieved within the next Sprint and most importantly HOW.

In practice, the two often blend, but it is of high importance to have steps and goal clarified to have things rolling out and get your team organized, and you will typically do that by breaking the Sprint Planning meeting into two parts:

Sprint Planning Part #1: Defining 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 or she will be the one responsible for reviewing, selecting, and presenting the highest priority Product Backlog items and asking the team to forecast and evaluate the functionality that will be developed.

For this first part of the meeting, it’s common for team members to go back and forth to the Product Owner with clarifying questions that will drive away uncertainty, define work, and guide 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 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.

Sprint Planning Part #2: Defining 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 the 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

Before the Sprint Planning meeting, the Product Owner should:

• Verify stakeholders’ priorities. If they have changed, the Product Owner should 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 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 give it a try and adapt it in your Sprint too?
  
• Check the Product Roadmap, so the Product Owner 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 before 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!

6 Tips on How to Run a Successful 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 in 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 before 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 in 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. Some teams 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 an 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 counterproductive 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.

The bottom line to make this whole process work for your organization, it’s to convince the participants and stakeholders involved that 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 in.

At the end of the day, optimizing the basics of Scrum will be the base to explore its mastery.

6. Analyze Your Sprint Planning Meetings During Retrospectives

Several issues that can prevent you from running successful Sprint Planning meetings, such as:

• Product Owner regularly demands from your team more output than it can deliver, thus demotivating it
  
• Teams skip defining the purpose of Sprints and feel lost after
  
• Sprint planning sessions are too long
  
• Team members don’t trust each other when evaluating tasks

The list of potential issues goes on and on. Although many of these issues are hidden and can sabotage your productivity and morale behind the scenes, successful agile teams easily reveal and fix them during retrospectives. 

Just make sure you allocate time and add specific questions such as “What did you like and dislike about the last Sprint Planning Session” during retrospectives to let your team members share their insights.

If you worry that your team members might not speak openly, conduct retrospective meetings directly in Slack to set them at ease. 

Tools such as Geekbot allow people to ask retrospective questions directly in Slack and later gather all the responses in a designated channel for further analysis.

In addition to that, you can customize retro questions, add icebreakers, define what members of your team you want to ask, and apply NLP-analysis to team responses in real time. 

We take pride in helping some of the most effective remote teams in the world to reach their full potential, so try Geekbot for free for 30 days and let us know how your team improved their workflow!