Retrospectives

Psychological safety is the key to high-performing teams. But how is it created?

Agility is the response to a complicated situation where unknowns override the knowns. A high-performing team is one where all members have their say, and there are multiple decision-makers. Psychological safety is the belief that the workplace is safe for speaking up about ideas, concerns or even failures.

But where does kindness fit in?

Kindness is the foundation for psychological safety.

Kindness is essential at each of the first three stages of Dr Timothy R. Clark 4 Stages of Psychological Safety model.

Stage 1: Inclusion Safety

Humans long to feel accepted before they need to be heard. As a leader, you can create inclusion by showing kindness by being aware, sensitive and curious about an employee’s life. A good starting place is; how was your weekend? How is the family this week? Have you got any exciting celebrations coming up? You seem a bit quiet today, is everything okay?

Stage 2: Learner Safety

Humans need to ask questions, give and receive feedback, and make mistakes whilst feeling safe. Showing kindness creates the trust to do so.

Stage 3: Contributor Safety

Humans need to feel safe to participate as team members. A commitment to kindness ensures greater information flow, higher quality connections at work, and an increase in collaboration.

Individuals thrive in environments with psychological safety. Fear triggers the self-censoring instinct, holding us back. When the environment nurtures psychological safety, there is an increase in confidence, engagement, and high performance.

3 Tips for Implementing Kindness in Your Team Today

Tip 1: Model kindness yourself. No matter your role, kindness is contagious. If you start acting kindly, this will soon spread to your whole team. You can serve with kindness by listening, working with forgiveness, offering a helping hand, showing concern, or celebrating significant events in a coworker's life.

To celebrate random acts of kindness day and live our Give Back company value, our team donated to Kind Hearts Illawarra.

Tip 2: Incorporate kindness into your team's ceremonies. Each team member can say one thing they are grateful for in the morning huddle. Each ceremony can leave room to give thanks to a fellow team member. At Easy Agile, we put this into practice by encouraging everyone to share a 'good thing' each day.

Tip 3: Implement Good Thnx in your company Slack. The Good Thnx Foundation provides a link between people and corporates that want to give and charities. As our team send “thanks” to one another, the recipient is given $50 to donate to a charity of their choice. Our contribution via Good Thnx for FY21 was $15,201.

Simply put, be kind today; it is free and enables high-performing agile teams!

Agile retrospectives offer opportunities for introspection. As with many things in life, the end is almost as important as the beginning. That’s why it’s important to improve what went wrong throughout the iteration and repeat what went well.

The retrospective meeting should be held at regular intervals to analyze team processes and outcomes. Reflecting on the last sprint should help guide the next one.

Sprint retrospectives are also informal but structured. Informality is a typical characteristic of the retrospective meeting, which motivates problem-solving.

In this article, we’ll review what an agile retrospective is, how to lead it successfully, and how to use the retrospective format.

What is an agile retrospective?

An agile retrospective is also known as the sprint or sailboat retrospective.

The Scrum Guide provides a clear definition of the agile retrospective. The Guide says the agile team can use the sprint retrospective as an opportunity to gather rapid feedback for continuous improvement. Continuous improvement takes place through ongoing teamwork and work analysis.

During the meeting, the team discusses what went well and what didn’t. They should identify the good, that they will aim to repeat as well as the areas to adjust, so the next sprint can go more smoothly.

Here’s how the 12 principles of the Agile Manifesto describes retrospectives: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

How to implement a sprint retrospective format

You can either implement the agile retrospective after each sprint, quarter, or the entire project. However, you should have a retrospective at regular intervals to continue iteration and improvements.

Use a retrospective format for each meeting. Creating a retrospective board is a great place to start, it sets the scene for the team involved and they know exactly what is expected.

We've added retrospective boards to Easy Agile TeamRhythm to help you and your team through more of the agile cycle, from planning through to review.

Here’s how to plan the sprint retrospective:

1. Preparation

Like a standup meeting, your preparation time for the retrospective should take about 15 minutes. The retro is like a lean coffee meeting where the agenda is relatively unstructured but democratic. Everyone gets to contribute.

Ideally, you want to have a retrospective board where team members can capture feedback as it arises. Be sure to remind team members to add their thoughts to the board prior to the meeting.

The retrospective board helps guide the retro process through tasks where the team fell short or excelled with action items. It also helps to identify areas of improvement and the actions the group must apply to effect change.

If in-person team members don’t use software to facilitate their agile retrospective, they can use another technique. This technique usually involves a whiteboard, Post-Its, and markers to guide brainstorming throughout the meeting.

Whichever methodology (Scrum or Kanban) the scrum master uses, a visual representation helps facilitate the best possible outcomes for future workflows.

Hot tip 🔥

It is best to rope in a neutral facilitator or agile coach to guide this process. This technique should help encourage team members to participate and share without feeling pressured.

2. Use the retrospective template to guide your agenda format

The retrospective board helps direct the agenda for the meeting format. Whether you choose start, stop, continue, glad, sad, mad, or our team's personal favourite - high notes, low notes and keeping the beat. Make sure you customise it to suit your teams needs.

Typically, the process follows six steps:

2.1 Set the stage

Refresh your memory about themes and stories in the last sprint if necessary. Set a timer and give the team a little extra time to add any last minute thoughts or items that may be missing

At the start of the retrospective, the Scrum master should introduce the product owner, team members, and other relevant stakeholders.

Welcome everyone and let them know that their participation is valuable. Inform team members that honesty is critical in producing positive outcomes. Ensure new teams know that questions are welcome, and that sharing experiences is vital to a successful sprint retrospective.

Throw in an icebreaker to set the tone of the meeting. A brief game of “two truths and one lie” can quickly promote a relaxed atmosphere if you have enough time.

Let the team know the amount of time it should take to complete each section of the sprint review. To keep everyone on track, the timer can come in handy again here.

2.2 Celebrate the wins

Congratulate team members who excelled. Discuss posting success stories on LinkedIn or elsewhere before moving on with the sprint review. Interact with items made on the retro board, react with an emoji or leave a comment.

2.3 Gather data

Data gathering includes collecting information from team members about sprint retrospective problems. The purpose is for the team to uncover the root cause of the problems.

Team members begin this process by sharing sprint experiences. Whether the experience was good, bad, or ugly—share it. It’s always a good idea to capture how everyone is feeling, take a mood survey to understand the overall team feeling.

Share the processes you used and which milestones you accomplished. If team members applied new technologies, share how those went. If they used new tools, let everyone know the pros and cons of each tool. Whatever the experience, let everyone know what worked well and what was a disappointment.

The Scrum master can facilitate this phase by using the “five whys” methodology. The “five whys” essentially refers to asking why a problem occurred, five times. Repeating the question multiple times supports deep thinking to get to the root cause of the problem.

2.4 Brainstorm solutions

Once the team members identify the shortcomings of the previous sprint, they can brainstorm solutions.

The team meeting should now revolve around associations between problems and solutions. Linking problems and solutions involves understanding. Once the team understands their mistakes, they can brainstorm several solutions to fix each problem area with better action items.

Throw in as many ideas as possible to have several solutions for consideration. Once the team has alignment on the action item, be sure to capture this so the appropriate next steps can be taken.

The retrospective board in TeamRhythm sits alongside your work in Jira, so that retrospective items can be added as the sprint or version progresses. Action items from the retrospective can be turned into Jira issues so that items worth actioning aren’t lost at the end of the discussion.

The Scrum master should also ensure that the team has the authority to follow through with relevant solutions at this stage. If they don’t have the authority to solve problems, the Scrum master must bump the issue up to a higher level.

2.5 Select viable solutions

Not all solutions from the brainstorming phase will be viable — ask the Scrum team, including the product owner, to choose three promising solutions for each problem. You can use different techniques to narrow this process, and ask team members to vote. You might want to try a dot vote, or up vote by giving the solution a thumbs up.

The simple vote requires everyone to select the solution that resonates best with them in the follow-up activity. In the dot vote, meeting participants find the best three solutions by placing a dot on three of the ideas they believe hold the most value.

Lastly, the multiple vote system means that the scrum master gives everyone points. The scrum team must then give these points to one or more of the best ideas.

2.6 End the meeting

End the meeting on a positive note before continuing to the next sprint. Try to leave with:

• A detailed synopsis of the previous sprint
• A detailed sprint planning exercise for the next sprint meeting
• Clear action items and next steps
• Collaborate as a team to determine whether this outcome is effective or needs improvements for the next iteration

3. Sprint retrospective meeting outcomes

Software development teams can use the S.M.A.R.T. criteria to analyze their solutions. Getting the product owner's inputs is a valuable part of the retrospective meetings as they diversify priorities and perceptions

The agile coach or Scrum master takes the S.M.A.R.T. solutions and translates these into item actions. The Scrum master should ask team members to take responsibility for activities to promote ownership and encourage behavioral change.

Once the product owner agrees, each activity should then become part of the backlog.

How to achieve successful retrospectives from in-depth introspection

An in-depth introspection promotes continuous improvement and productivity. Following a retrospective template helps achieve these goals, while supporting integrated teamwork. The product owner also benefits from your team efforts with each sprint retrospective, which is a primary objective.

Gain team alignment with team retrospectives

Easy Agile TeamRhythm supports agile retrospectives, helping you and your team gain a shared understanding of the work, and how you work best together. Designed for Jira users, our goal is to help agile teams work together effectively.

Try Easy Agile TeamRhythm free for 30 days

Planning is a critical phase of the agile process; it's an opportunity to align on priorities as team and organize work in a sequence that will help it run smoothly. The planning process helps agile software development and other product development teams sort through new information, adapt to dependencies, and address evolving customer needs.

Agile is the opposite of traditional waterfall project planning, which takes a step-by-step approach. Waterfall has dominated project planning for many years, with detailed plans laid out at the beginning of a project that had to be adhered to rigidly. This may move a project or product forward, but it neglects to account for any new developments that could occur outside of the “master plan.”

Agile is an iterative process that helps teams reduce waste and maximize efficiency for the ultimate goal of bringing value to customers. This customer-first approach helps teams make informed choices throughout the development process — choices that continually and consistently provide value to stakeholders.

One of the greatest advantages of an iterative agile approach is that it enables early feedback from stakeholders. You don’t need to guess whether or not you’re making the right decisions — you can find out every step of the way by directly including stakeholders in your process. You can adapt your plan as you need to based on what will provide the most value to customers at any time.

Even if you are part of a seasoned agile team, there are always opportunities for improvement and processes to fine-tune. This post will outline some unproductive agile planning mistakes teams make, including how agile teams can avoid these common pitfalls.

Agile Planning Mistake #1: Not being on the same page as stakeholders

Do you involve stakeholders in your planning process? Do they understand your goals and why you are making each decision? Working directly with stakeholders, both internal stakeholders and the users of your product, will help you gain a clear view of both needs and constraints, and give you the information you need to determine what should be done when.

It's never a good idea to rest on assumptions. Your stakeholders live in a different world than the one you are deeply embedded in, with different priorities and assumptions of their own. So that you can produce deliverables that meet stakeholder expectations, you need to agree on what those expectations are. Involve your stakeholders in planning, but ensure everyone understands that expectations could evolve throughout the process based on new information gained from successes, failures, and customer responses.

Agile Planning Mistake #2: Not accounting for dependencies

Failing to account for dependencies in agile planning leads to bottlenecks, delayed releases, and undermines team collaboration. Collaboration within and across teams is needed for a business to deliver effectively. When multiple teams are working on interconnected features, if one team’s progress is blocked by another, the entire development cycle slows down. Without clear visibility of dependencies, work can be delayed and deadlines missed.

To minimize and avoid disruption to the flow of work, take the time to consult with stakeholders and anticipate dependencies early. Tools that help you visualise and map dependencies, and shared roadmaps to track cross-team dependencies, allow you to share an understanding of dependencies and sequence work in a way that avoids roadblocks. Proactively managing dependencies ensures smoother iterations, faster time-to-market, and a more predictable agile process.

Agile Planning Mistake #3: Using bland, flat product maps

Flat product backlogs are bland and boring 😴. Think carrot cake without icing. They lack the detail and functionality needed to realize the full story of your product backlog.

Plus, once you have more than a handful of items, they become overwhelming and difficult to organize in a meaningful way. It becomes less clear which item is the most important and more difficult to ensure your decisions align with the larger goal of the project.

When you plan out your roadmap, it needs context, and you must be able to clearly see the customer journey. User story maps visualize the customer journey in the planning process and throughout the entire process of product development. They utilize user stories — the smallest unit of work that can bring value to the customer — so you can plan and organize the backlog from the customer’s perspective.

📕 Read our ultimate guide to user story maps to learn more.

Agile Planning Mistake #4: Not allowing the plan to live, breathe, and adapt

As we've already discussed, agile is an iterative approach. This means your agile planning needs to leave room for changes. Your plan should be able to grow and adapt as you progress with each sprint or product roadmap.

At the beginning of a sprint, you lack the information needed to see the full picture. You don’t have everything you need to build the perfect solution, and that’s okay. It’s all part of the process. Spending hours or days trying to iron out the perfect plan just wastes time that could be better spent learning and solving problems as they come. What you thought would provide the most value during the planning phase could be completely different down the track.

You may need to alter your plan after a roadblock comes up in a daily stand-up, or you may learn about a customer concern that completely changes your direction. Iterations are inevitable and welcomed! They help you keep pace with incoming information as you learn from each other, stakeholders, and your customers.

Agile planning isn’t a promise. It’s an outline that will help you reach your goal, and that changes with your goals and circumstances.

Agile Planning Mistake #5: Not incorporating retrospective insights in the following planning session

Retrospectives are an essential piece of the agile process. They give teams a chance to reflect on everything that occurred in an individual sprint or after the completion of a product.

An effective retrospective asks the entire team key questions that can improve the process next time around. What went well? What’s worth repeating again? What didn’t go so well? What could be improved upon next time? What roadblocks or dependencies developed? What did you learn? How did you feel at the end of the sprint?

A retrospective provides insights that will improve efficiency, teamwork and team dynamics, the effectiveness of tools, and communication with stakeholders.

Simply holding a retrospective or collecting retrospective feedback is not enough to gain value. You need to ensure you’re incorporating the feedback into the following sprint planning meeting, and take action that leads to meaningful improvement. The next iteration will be all the better for the time you spend reflecting and improving based upon what you learned.

Agile Planning Mistake #6: Choosing tools that don’t take a customer-centric approach

Whether your team uses a Scrum process, kanban boards, or other agile methods, the tools you choose should always be customer-focused. And you need to continue using them in a way that keeps the customer at the forefront of decision making.

Teams can fall into a trap believing they’re focusing on the customer when they aren’t doing much of anything beyond following simple agile methods and generic processes. Customers need to be embedded in your development process right from the planning phase so that every decision a team member makes considers customer needs first.

Choose planning tools that help your entire team get to the heart of what makes your customers tick, and always check in to ensure you are making decisions in line with your customers.

For example, Personas provide a deep understanding of what customers want, need, don’t want, etc. They reveal key information about customer pain points, desires, demographics, goals, shopping patterns, and much more. We highly suggest developing customer Personas to get a rich picture of all the people who will use your product, but it’s not enough to just have Personas lying around.

You need to bring these Personas into your agile planning process and keep them front and center as you complete issues and continue to develop your product.

We’re off to the races! 🏃🏃‍♀️ Sprints are a key component of agile methodology. A sprint is a predefined time period in which agile teams work together towards an agreed-upon sprint goal. There are four types of agile meetings that occur over the course of a sprint, and each is vital to ensuring the success of the agile process. It’s all about sprinting through a predetermined amount of work to get to the finish line, where you learn from your process and begin the race again (only better off because of what you learned during the previous sprint).

Agile meetings are used to get team members, leaders, and stakeholders on the same page, and they guide the process of an agile sprint or Scrum.

This post will cover the four key agile meetings, which include sprint planning, daily standups, sprint reviews, and sprint retrospectives. Plus, we’ll discuss a bonus agile meeting that’s utilized for backlog refinement.

Agile meetings vs. Scrum meetings

Scrum is an agile methodology that’s most commonly used in software development. Scrum meetings are technically a type of agile meeting, but they have more specific parameters designed to fit within the Scrum framework. The process revolves around a 2-4 week sprint involving a product owner, Scrum Master, and the entire Scrum team.

We covered Scrum meetings (ceremonies) in detail in another article. For the purposes of this post, we’ll focus on the four main agile meeting types. These processes and best practices can be applied across multiple agile methodologies, including Scrum and Kanban. This framework can also be applied across industries beyond software development and can adapt to the needs of most teams.

Simply put: Scrum has a more rigid framework that follows four ceremonies/meetings. The agile process is much the same, with four very similar meetings, but there’s more flexibility to adjust the time frame of the sprint and adapt the process when not following Scrum guidelines specifically. Okay, maybe that’s still not simply put, but it wouldn’t be agile if it was linear and straightforward.

The 4 types of agile meetings

There are four central agile meetings: sprint planning, daily standups, sprint reviews, and sprint retrospective meetings. A sprint starts with a sprint planning meeting. Each day, a daily standup meeting is held. Finally, at the end of the sprint, a sprint review and retrospective are held. The process repeats with new springs until the product, project, or work is complete.

1. Sprint planning meeting

The sprint planning meeting occurs at the beginning of a sprint and involves the entire team. In sprint planning, the entire team meets to discuss and agree upon which work tasks (backlog items) should be moved to the sprint backlog — the items that need to be completed by the end of the sprint. During the meeting, sprint goals are determined, and the team aligns on expectations.

Without a sprint planning meeting to outline the sprint backlog (tasks that need to be completed), the team will waste time during the sprint trying to determine which work takes precedent.

Sprint planning mistakes to avoid:

• Starting planning without a refined backlog
• Not being on the same page as your stakeholders
• Ignoring the customer and the customer journey when making plans
• Creating a rigid plan that doesn’t have room to grow or adapt
• Using bland, flat product maps that lack critical context
• Failing to incorporate retrospective insights in the following planning session

Learn more about common agile planning mistakes and how your development team can avoid these pitfalls.

2. Daily standup meeting

The daily standup meeting occurs every day of the sprint. In the Scrum process, this meeting might also be called the daily Scrum meeting. It’s a chance for the team to connect about the work that was completed the previous day and what each person or team plans to complete over the course of the next 24 hours.

The meeting aims to answer three important questions:

• What work was completed since the last standup to help the team reach the sprint goal?
• What work do you plan to complete today?
• Is there anything currently in your way or hindering your progress?

This is a good time to address any bottlenecks. If work planned from the previous day wasn’t completed, what caused the delay, and how can the team work together to solve any problems keeping the work from moving forward?

A standup meeting is short and to the point so everyone can get back to the work they hope to complete. So short that it’s often recommended participants stand for the duration of the meeting. Hence the name daily standup. It includes all team members and ideally takes place at the same time every day to ensure everyone can always attend.

Daily standup mistakes to avoid:

• Not keeping track of the time during the meeting
• Continually going over the allotted meeting time
• Rambling participants who aren’t prepared to answer the meeting’s key questions
• Skipping the meeting due to lack of time
• Team members showing up late to the meeting or missing it altogether
• Allowing the loudest voices to overshadow the rest of the team
• Letting someone state the same task on multiple consecutive days
• Failing to address potential bottlenecks
• Assigning work beyond a person's capacity

3. Sprint review meeting

The sprint review is an opportunity for the team to showcase the work they accomplished during the sprint. This meeting might be an internal presentation or a more formal demo to stakeholders, depending on the needs of the project and how far along work is.

Sprint review mistakes to avoid:

• Not properly preparing for the meeting or demonstration
• Not bringing stakeholders in on your process
• Failing to demonstrate how the work brings value to the customer
• Exaggerating or embellishing successes
• Failing to address any problems and how they were solved
• Not incorporating sprint review feedback into the next sprint planning meeting

4. Sprint retrospective meeting

The retrospective is a crucial part of the agile process. The meeting comes at the end of the sprint, bringing the entire team together to assess their processes and discuss how they can improve next time.

Which aspects of the sprint went well, and what can you learn from that success? What didn’t go so well, and what bottlenecks did the team hit? What could be done better next time? Since agile is all about learning and iterating, there are lessons to be learned after each sprint. Everything from the good to the bad to the mediocre can be transformed into actionable improvements.

Retrospective mistakes to avoid:

• Blaming individual team members for bottlenecks
• Allowing only the loudest voices to provide insight
• Failing to empower the softer voices in the room
• Repeating the same questions over and over without changing things up
• Allowing the retrospective to run too long (aim for two hours for a two-week sprint)
• Skipping a retrospective due to a lack of time or resources
• Forgetting about or not including stakeholder insights or needs
• Failing to improve upon the sprint retrospective process (retrospective the retrospective!)
• Failing to incorporate retrospective insights in the next sprint

Bonus: Backlog refinement meeting

It could be argued that there’s a fifth agile meeting, especially in the product development world. Before the sprint planning meeting, the product owner must create a product backlog, which comprises all of the tasks and items the team needs to complete in order to fully develop the end product or project. The items include user stories, bug fixes, features, and other tasks that must be addressed to achieve the end goal.

Backlog refinement prepares the backlog for sprint planning by ordering items to deliver the most impact over the next sprint. During backlog refinement, a product owner ensures that product backlog items contain enough information, detail, and prioritization for the team to make smart decisions about what to tackle when.

A meeting to refine the backlog may occur before sprint planning begins, depending on the current state of the product backlog. Outside of the product development industry, the product backlog might be akin to a master project task list.

Backlog refinement meeting mistakes to avoid:

• Not completing backlog refinement in time for sprint planning
• Leaving too much backlog refinement for the planning meeting
• Failing to prioritize items that provide customer value
• Not incorporating new stakeholder feedback, questions, and concerns

Agile meetings: Final review

So there you have it! The four key agile meetings are sprint planning, daily standups, sprint reviews, and sprint retrospectives, with an honorable mention going out to backlog refinement.

Let’s review each meeting’s purpose:

• Sprint planning gets everyone on the same page about what needs to be accomplished over the course of the coming sprint.
• Daily standups ensure the team stays on track and helps them address and resolve any potential bottlenecks.
• Sprint reviews are an opportunity for the team to showcase the work accomplished during the sprint to stakeholders and receive critical feedback.
• Sprint retrospectives allow the team to come together to discuss what went well, what didn’t go well, and how they can improve next time.
• Backlog refinement prepares the backlog for sprint planning in order to deliver the most impact over the next sprint.

Hold effective agile meetings with Easy Agile

Easy Agile is committed to helping teams work better with agile. Easy Agile builds products specifically designed for Jira users to help agile teams work more efficiently and effectively.

We regularly publish lists of tools, advice articles, and how-to guides for agile teams. If you work with Jira, you’ll find our resources are especially helpful in navigating the ins and outs of product development and the Jira apps that will improve the way your team collaborates.

This guide looks at the four ceremonies that bring one of Agile’s most popular frameworks, Scrum, to life.

Learn how each agile ritual helps empower teams and drive performance while highlighting some tips to help your organization get the most from your ceremonies.

At a glance:

• The four agile ceremonies are Sprint Planning, Daily Stand-Up, Sprint Review and Sprint Retrospective
• Ceremonies in agile facilitate visibility, transparency, and collaboration.
• Each ceremony has a clear structure and objective.
• Clear communication, flexibility, and cultural alignment are the keys to successful ceremonies.

What are the main agile ceremonies?

Agile ceremonies refer to the four events that occur during a Scrum sprint. Other forms of agile development, such as Kanban and Lean, also have similar practices.

The agile ceremonies list includes:

1. Sprint Planning
2. Daily Stand-Up
3. Sprint Review
4. Sprint Retrospective

While each ceremony is different, they facilitate the same overall purpose. The ceremonies bring teams together with a common goal under a regular rhythm, and they help teams get things done.

"With today's enterprises under increased pressure to respond quickly to the needs of their customers and stakeholders, they must bring new products to market faster and accelerate improvements to existing solutions and services." - State of Agile Report

Why are agile ceremonies important?

Agile ceremonies help organizations adapt to change and succeed. With work planned in smaller portions and over shorter timeframes, they help teams quickly shift direction and course-correct when needed. They form a key part of the broader agile approach that’s now widely adopted in organizations worldwide.

With agile ceremonies, teams in your organization can benefit from:

• Enhanced ability to manage changing priorities
• Acceleration of software development
• Increase in team productivity
• Improved business and IT alignment

It’s important to remember that while ceremonies are an essential part of Scrum, they’re just one of many rituals that help create agile teams and workplaces. To realize the true benefits of agile, you’ll need to do more than include one or more of the ceremonies into your waterfall project.

1. Sprint Planning

The Sprint Planning ceremony sets teams up for success by ensuring everyone understands the sprint goals and how to achieve them.

• Structure - The Product Owner brings the product backlog to discuss with the Development Team. The Scrum Master facilitates. Together, the Scrum Team does effort or story point estimations. The product backlog must contain all the details necessary for estimation. The Product Owner should be able to clarify any doubts regarding the product backlog.

• Attendees - The entire Scrum Team (the Development Team, Scrum Master, and Product Owner).‍

• Timing - At the beginning of each sprint.‍

• Duration - One to two hours per week of iteration. So, if you're planning a two-week sprint, your Sprint Planning should last two to four hours. ‍

• Agile Framework - Scrum. Although Kanban teams also plan, they do it less formally and per milestone, not iteration.

Outcomes

After some team negotiation and discussion, you should have a clear decision on the work that the Development Team can complete during the sprint by the end of Sprint Planning. This is known as the sprint goal.

The sprint goal is an increment of complete work, and everyone should feel confident about the commitment.

The product backlog defines priorities that affect the order of work. Then, the Scrum Master transforms that decision into the sprint backlog.

Top tips

• Focus on collaboration rather than competition.
• Break user stories into tasks to get things more operational for the Development Team. If there's time, assign those tasks during the event.
• Factor in public holidays and any team member’s time off or vacations.
• Keep your team’s pace in mind – a track record of the time it took to implement similar user stories would be helpful.
• Focus on the product backlog and nothing else in terms of work for the sprint.

2. Daily Stand-Up

The daily stand-up brings the team together and sets everyone up for the day. The team uses this time to identify blockers and share plans for the day.

• Structure - This is an informal, standing meeting. All members of the Development Team inform everyone about what they did the day before and what they’re doing today. Members discuss any blockages they have and ask for help from the team if required. Due to time restrictions, the updates should be brief.

• Attendees - Development Team, Scrum Master, Product Owner (optional).

• Timing - Daily, usually in the morning.

• Duration - Short and sharp. No longer than 15 minutes.

• Agile framework - Scrum and Kanban.

Outcomes

The Scrum Master should clear all the blockages that slow down or prevent the Development Team from delivering. As a result, the development process might need to change.

This daily pulse check keeps the team in sync and helps build trust. Together, the group finds ways to support and help each other.

Top tips

• Use a timer to keep this meeting to 15 minutes.
• Hold your stand-up at the same time every day.
• Only discuss the work for the day ahead.
• If the team is distributed, use video conferencing with cameras on.
• Long discussions should happen after the event.
• As the stand-up encourages progress, everyone should provide an update, and everyone should feel accountable.

3. Sprint Review

The Sprint Review is the time to showcase the team’s completed work and gather feedback from stakeholders. A variety of attendees from outside the team offer valuable insights from different viewpoints. This event also helps build trust with both external and internal stakeholders.

• Structure - The Scrum Master takes on the logistics of event preparation. The Product Owner should ask stakeholders questions to gather as much feedback as possible. They should also answer any of their stakeholder’s questions.

• Attendees - Development Team, Scrum Master, Product Owner. Optionally, management, customers, developers, and other stakeholders.

• Timing - At the end of the sprint.

• Duration - In a one-week sprint, the Sprint Review lasts one hour.

• Agile framework - Scrum and Kanban. Kanban teams do these reviews after the team milestones, not sprints.

Outcomes

After this ceremony, the Product Owner might need to adjust or add to the product backlog. They might also release product functionality if it's already complete.

Top tips

• Schedule in time to rehearse before the meeting to help your team present with confidence, especially if external stakeholders are coming along.
• Don’t showcase incomplete work. Review your Sprint Planning and the original criteria if you’re not sure whether the work is complete.
• Besides product functionality, focus on user experience, customer value, and the delivered business value.
• Consider ways you can introduce a celebratory feel to acknowledge the team’s effort.

4. Sprint Retrospective

In this final scrum ceremony in the sequence, you look back on the work you’ve just done and identify ways to do things better next time. The Sprint Retrospective is a tool for risk mitigation in future sprints.

• Structure - The teams discuss what went well throughout the sprint and what went wrong. The Scrum Master should encourage the Development Team to speak up and share not only facts but also their feelings. The goal is to gather rapid feedback for continuous improvement in terms of process. It’s also an opportunity to emphasize good practices that the team adopted and should repeat.

• Attendees - Development Team, Scrum Master, Product Owner (optional).

• Timing - At the end of the sprint.

• Duration - 45 minutes per sprint week.

• Agile framework - Scrum and Kanban (occasionally).

Outcomes

After this session, the team should clearly understand the problems and the wins that happened throughout the iteration. Together, the group comes up with solutions and an action plan to prevent and identify process problems in the next sprint.

Top tips

• Focus on both facts and feelings
• Gather information that helps you focus on continuous improvement – this might include tools and relationships
• Be honest and encourage ideas that solve process-related problems
• Even if everything went well, have this meeting – retrospectives provide ongoing guidance for the next sprint.

"With the speed of change expected to continue, the need has never been greater for an operating model that keep up." - McKinsey

Agile lessons to live by

As a team of experienced agile practitioners, we’ve picked up some key learnings about what it takes to get the most out of your agile ceremonies and create the foundations of a truly agile organization.

Here are our top tips to make your ceremonies a success:

• Be deliberately present - During the ceremonies, remember to take moments to pause and remind yourself of why you’re there. Show others that you’re present by giving them full attention and using your body language. In a remote setting, angle your camera as though you’re sitting across from them, look into the lens regularly, and use a distraction-free background.
• Practice active listening - Think about what the person is saying, who they are, and what they need from you. Are they looking for a soundboard, do they need your help or opinion, or are they looking for an emotional connection?
• Understand motives - Understand the motivations of your teammates before speaking. Consider why they should care about what you’re saying by connecting your message with their own motivations. Provide context where possible to let them know why your message matters.
• Be flexible - It's important to remember that there is not a one size fits all approach to agile ways of working. What works for one team may not work for another, so you need to experiment to find out what works then tailor processes to suit your team's needs.
• Create cultural alignment - The best processes in the world won’t deliver what you need if you don’t have the culture to support their delivery. Agile ceremonies need to be supported by a culture where people are actively engaged, confident to raise issues, and value continuous improvement.

Agile ceremonies lead to better results

While it can take time for teams new to agile to adjust to agile ceremonies, they are worth the effort. By providing a clear structure and achievable outcomes, they help align everyone on the product, communication, and priorities.

The result? Agile teams that provide better quality products faster – and deliver real business outcomes.

Wherever your organization is on your agile journey, it’s worth keeping in mind that each team and each suite of products are different, so there’s no standard recipe for success. The good news is that by working within the continuous improvement mindset the agile framework promotes; you too can iterate and improve your agile ceremonies over time.

Ready to get started?

Easy Agile TeamRhythm supports your team's agile practices in Jira. Supporting your team from planning right through to retrospective, TeamRhythm helps you and your team work better together to deliver value to your customers.

Features include:

• Agile sprint and version planning tool - Planning is quick and easy when you create and estimate issues on the story map. View your work under initiatives and epics, and see swimlane stats at a glance, ensuring team capacity is filled but not overcommitted
• Agile story mapping - Map the customer journey using initiatives, epics, and stories alongside your agile Jira boards. Quickly and easily add new or existing stories inside the story map. Drag and drop to prioritize by value to the customer.
• Product backlog refinement - Escape your flat backlog and view your work on the story map matrix. Drag and drop issues to prioritize or schedule. Quickly update story summaries and story point estimates with inline editing for a better backlog.
• Team retrospectives - Celebrate success, gain insights, and share learnings with team retrospective boards for scrum and kanban, encouraging collaboration and transparency, so you and your team are continuously improving.

PI planning is a powerful event that helps teams align around goals, business objectives, and customer needs. Traditionally, this quarterly gathering brought together large teams of more than 100 people, including software developers and stakeholders, to complete essential planning.

However, in our new world of work, virtual PI planning has become necessary. This shift presents its own set of challenges, such as implementing virtual tools, overcoming time zone differences, and coordinating employees who are accustomed to working on their own schedules. Not to mention the occasional tech glitches that may arise.

In this blog, we will explore the information technology industry as an example and delve into how they can benefit from PI planning. Discover the critical benefits of PI planning and provide strategies for successfully conducting hybrid PI planning. Whether you're a newcomer or an experienced master in agile practices, there's always room for improvement in optimizing your systems.

What is PI planning?

PI planning, or Big Room Planning planning, is typically a two-day event that brings together all of the teams on an agile release train, including product owners, facilitators, developers, and outside stakeholders. It’s traditionally a face-to-face planning session that, for some teams, puts more than 100 people in the same room to align on goals, business objectives, and an overall direction moving forward.

It’s part of a scaled agile framework that implements agile practices for enterprises. Agile teams use repeated workflows for informed planning, efficient execution, and continual delivery of stakeholder value.

Although PI planning events often take place in person, the increased number of remote teams has forced businesses to find hybrid solutions for this large-scale event.

Equip your remote, distributed or co-located teams for success with a digital tool for PI Planning.

Try Easy Agile Programs for Jira

Free Trial

The benefits PI planning

Whether PI planning occurs in-person, online, or hybrid, this two-day gathering provides a number of critical benefits. It’s an integral part of SAFe that keeps businesses aligned on common goals and objectives, and it sets various teams on a strong path for upcoming sprints.

The PI planning event can bring numerous benefits. Here's 5 potential advantages for the information technology (IT) industry:

• Collaborative Environment: The PI Planning event provides a space where IT professionals from various teams and departments can come together to collaborate, brainstorm, and share ideas in a face-to-face setting.
• Cross-Functional Communication: IT often involves multiple departments (development, operations, support, etc.). The PI Planning event facilitates better communication and alignment between these departments, leading to more cohesive strategies.
• Focused Decision-Making: A dedicated event allows for focused discussions and decisions, reducing distractions that might arise in regular office settings.
• Rapid Problem Resolution: Complex IT challenges can be addressed more efficiently when all relevant stakeholders are physically present to discuss issues and propose solutions.
• Knowledge Sharing: Experts from different IT domains can share their expertise, leading to increased learning and skill development across the organization.

8 PI planning strategies

In order to ensure a successful PI Planning event you need to have some strategies in place to help teams effectively collaborate and align their efforts, whether they are co-located or working remotely. Here are some strategies to consider:

1. Set the date and agenda early

It is imperative to schedule the session well in advance, allowing team members to allocate the necessary time and prioritize their participation amidst their busy schedules. It is of utmost importance to encourage widespread participation in this planning session.

Providing a comprehensive agenda for the event is crucial for ensuring effective collaboration and alignment within teams. The agenda serves as a roadmap, guiding participants through the planning session and helping them prioritize their contributions.

By setting a clear agenda, teams can establish a shared understanding of the objectives, topics, and activities to be covered during the PI Planning session.

2. Set Clear Objectives

Before the PI Planning event, establish clear objectives and goals that you want to achieve. Communicate these objectives to all participants so that everyone is aligned and understands what needs to be accomplished during the event. This will help keep the focus on the desired outcomes and ensure a successful planning session.

3. Choose stellar tools that aid collaboration

Utilise visual tools to encourage active participation and facilitate visual representation of ideas and plans. Choosing the right tools can make a significant difference in enhancing productivity and promoting effective teamwork. The chosen tools should aid in organizing and structuring information, making it easier for team members to comprehend the work and dependencies, allowing the teams to collaborate in real time. It is essential to choose visual collaboration tools that are user-friendly, intuitive, and accessible to all team members.

Virtual whiteboards, such as Miro, are also a huge asset, as well as tools designed for PI Planning. If your team uses Jira, we recommend Easy Agile Programs. It’s a complete solution designed for distributed, remote, or face-to-face PI Planning.

4. Go in with a refined backlog

Do as much advance planning as you can so you can make the most of this planning event. Ensure the backlog is thoroughly refined and ready to go so no time is wasted during PI planning.

It’s a big commitment for so many people available at once, and it uses up a lot of working hours. Plus, your stakeholders are setting aside time for this meeting. A refined backlog that’s organized with appropriate details will keep everything running as smoothly as possible.

5. Don’t have people waiting around

Do all you can to ensure there’s a clear schedule that doesn’t leave anyone hanging around. That last thing you want is to waste people’s time. Ensure people know “where” they need to be and when. Triple-check that the appropriate people are assigned to virtual meetings, breakouts, and tasks. Advance planning and transparency will help ensure no one is left waiting or underutilized.

6. Utilize team breakouts

It’s unrealistic to have 100+ people working together in the same room or virtual space for two days straight. Can you imagine? 🤯

Breakout meetings composed of smaller groups are essential to a productive and effective planning event. Once again, it all comes down to advance planning. Your game plan doesn’t need to be completely rigid, but you do need a clear schedule, and leaders need to effectively organize breakout groups in whatever way makes the most sense for your team and desired planning outcomes.

TIP: Your tools can come in handy here, set up dedicated team planning boards to help facilitate conversations and capture the work. Below is an example of a Team Planning Board in Easy Agile Programs. What you are seeing is an example of how a team can create issues on their board and create any dependencies they might have in their team and between teams.

7. Expect the unexpected and roll with the punches (aka tech issues)

As with any large-scale meeting, nothing is going to run perfectly. You are bound to run into hiccups and tech issues. Rolling with the punches is the best you can do.

Test technology in advance — schedule time when your main speakers can do a test call with you. Go over requirements, and have them silence notifications and devices in advance.

Make sure everyone has the information they need to operate their tools and tech effectively, and as the leader of the event or a breakout session, have tech contingencies in place. What happens if your conferencing tool stops working? Do you have a backup? What if their Wi-Fi slows or goes down? Can they switch to a hotspot or can someone else take over?

8. Hold a retrospective so you can improve the next time around

Retrospectives ensure your processes continually improve. They provide an opportunity for feedback that will help make the next big planning meeting better.

Make sure you collect feedback and hear people out after the session. Ask people what they thought went well, what didn’t go so well, and what could be improved for next time. Use this information to improve the process for your next big room planning meeting.

Explore Easy Agile TeamRhythm

By following these strategies, you can facilitate effective collaboration and alignment within your teams during the PI Planning event.

PI planning with Easy Agile

No matter the size of your team, effective planning begins with using the right tools. Easy Agile builds products specifically designed for Jira users to help agile teams plan efficiently and effectively.

Watch Demo

Easy Agile Programs for Jira is ideal for helping remote or distributed teams effectively manage programs with streamlined visibility to deliver alignment at scale. Set PI objectives, visualize dependencies, and align the entire team with a simple-to-use and virtually accessible tool.

Try free for 30 days