How to Play Planning Poker and Involve the Whole Team in Estimates
Let's face it! Project management for agile teams can include a lot of tough calls, from managing product owner expectations or undefined quality standards.
Sure, you have good days and bad days. But why not set your sights higher and aim for the ideal day?
To help you do just that, planning poker, also called Scrum poker, uses playing cards to simplify agile estimating and planning. The result? Your agile estimating and planning process runs more smoothly, and your development team increases its productivity.
In this article, you’ll explore the driving force behind planning poker, how it helps estimation, planning poker’s history, and how to play this game.
The driving force behind planning poker
The purpose of planning poker is engaging the whole team in collaboration. Scrum poker makes it easier to make valuable time and effort estimates so your team can create satisfying deliverables.
Instead of team members verbally expressing their estimates, they use a deck of playing cards to speak for them. Drawing cards and simultaneously placing these playing cards face down eliminates bias. Everyone follows this route in the estimation process, which supports individual estimates and negates peer influence.
Other project estimation techniques use time to determine how long a task will take. Agile estimation uses story points. These story points refer to the level of effort to undertake a task.
In planning poker, the whole team assigns story points to each task. Each story point is a visual representation of the amount of work to be done and the effort that must go into completing each task. This method wins out over time since it is visual and focuses on effort involved instead of time constraints
Work estimation in agile development
The estimation process is vital to team members because it determines how much work will go into each sprint. Dividing the product backlog into bite-sized tasks helps evaluate the workload.
As a Scrum master, you have a difficult role to play. At the end of the ideal day, you want the product owner's user story to be exemplary. Simultaneously, as the Scrum master, you have a Scrum team to manage.
Agile development is a critical process that you need to control. Get the user story and story points right, and you're halfway there. Master the estimation process and sprint planning, and you control the product backlog and retrospective.
Software development teams can either use physical playing cards or software for planning poker. Using software that includes a Jira plugin is vital when you have distributed teams. When you have a Jira plugin, everyone can participate in and streamline the estimation process.
History of planning poker
Software development teams used to use another team-based estimation technique, Wideband Delphi. Although similar to planning poker, it took too much time to reach consensus with this technique.
James Grenning found that Delphi didn't work as a structured estimating approach and came up with the idea of playing poker in 2002. Grenning found that a physical deck of cards was an engaging approach for agile teams to make work estimates. He also found that Scrum poker worked better than Wideband Delphi.
Planning poker is more inclusive. The deck of cards ensures Scrum team participation in work estimates, and everyone must continue to participate until consensus is reached.
In 2002, Mike Cohn developed mountain goat software and stepped in with a deck of digital cards to use in planning poker. Scrum teams can use these digital playing cards from remote locations to improve agile estimating and planning and have some fun along the way.
Let's explore the ins and outs of the poker session and how to play the game.
What Scrum teams need for a poker session
Agile teams need a few essential items for their planning sessions. These items include:
- A deck of cards
- Estimators (the agile team)
- A moderator
- A features list
- An egg timer
Choose your playing cards
In Scrum poker, team members (estimators) each have a deck of cards. They use these playing cards to indicate their high or low estimate on how long each item on the list of features will take to complete. These list features can be the user story, story points, or ideal days to complete sprint planning.
The playing cards the development team use will follow a Fibonacci sequence. This Fibonacci sequence follows the 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 pattern, where each consecutive number is the sum of the two preceding numbers.
Alternatively, team members can use a different deck of cards where the value of each number has a fixed ratio, such as 1, 2, 4, 8, 10, 12 and so on.
Different card decks provide adapted sequences, such as 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Other commercial decks have cards to indicate that the agile team needs a coffee break or an infinity symbol which means that it is impossible to complete a task.
Similarly, team members can adopt a standard deck of cards for Scrum poker. Here, the team members use the Ace, the 2, 3, 5, 8, and the King.
How to play Scrum poker
Every Scrum team will have different goals, but the general sequence for playing planning poker is as follows:
- All team members have their own deck of cards except for the moderator.
- Team members ask the moderator (often the product owner) questions about themes, user stories, story points, product backlogs, agile retrospectives, or whatever else they need for their agile estimating and planning process. Questions typically surround the product owner's acceptance criteria. Questions can include whether the backlog items are complete and what the next best step is to complete the sprint.
- Once the moderator answers the agile team's questions, each team member selects a card estimate. That represents how long they think the work item will take.
- Team members then place their cards, face down, on the table or use a Jira plugin for distributed teams.
- Playing cards are placed face down to prevent anchoring, or influencing each other's evaluations.
- The moderator reveals the Scrum team's cards to view their estimates.
- If team members have a high or low estimate compared to other team members, they need to explain their reasoning. The agile team can ask more questions for clarification. This questioning period is often limited by using an egg timer.
- The process is repeated until the agile team agrees on the estimate of how long it’ll take to complete each user story.
- Agreement is frequently reached on the second or third draw of the playing cards for each work item.
Agile estimation that involves the whole team
Planning poker is an accurate, collaborative, team-building method of estimating the work for each user story.
While you prepare to use planning poker in your next product roadmap planning meeting, consider Easy Agile TeamRhythm. The app helps you group Jira items into themes so stakeholders can easily keep track.
Related Articles
WorkflowPlanning Poker — Agile Estimation Technique How-to Guide
One of the core functions of an agile software development team is effort estimation. You can't properly prioritize a product backlog without first having an idea of the amount of work it will take to finish each of its user stories. One agile estimation technique is planning poker. Agile development is a collaborative pursuit, and planning poker is a consensus-building exercise that gets your entire team involved in the estimation process.
Software development teams use planning poker to assign effort (for example, story points or ideal days) to items in their product backlog. Sometimes also called Scrum poker, it's a gamified way to build consensus by allowing all of the Scrum team members to participate in the estimation process. Physical or digital poker cards are used to facilitate a collaborative planning session. ♠️
Here, we give you a how-to guide to planning poker. First, we'll show you how to play it in the context of a sprint planning meeting. Second, we'll look at some of its benefits as an estimation technique. Then, we'll see why planning poker can be used in product roadmap planning. It can help get your stakeholders involved in a consensus-building estimation session around your product's customer themes.
Playing planning poker — agile collaboration
One of the critical activities for agile teams during a sprint planning session is estimating the amount of effort it will take to complete each user story in the sprint. A common way to do this is to allow a single person, like the product owner or a software developer, to assign story points to each user story. Alternatively, you can use planning poker as an estimating technique to get the whole team involved.
A planning poker session is a fun and collaborative way to gamify sprint planning. After all, the Agile Manifesto highlights the value of collaboration and interactions in software development. Planning poker is a great way to adhere to those agile principles.
So, it's sprint planning day. When your team members are gathered, do the following:
- Set the stage. If your team is new to planning poker, explain the process. They'll use playing cards to estimate the size of each user story in the next sprint iteration. The product owner or Scrum master will act as the moderator, all team members will play, and there will be plenty of room for discussion and questions throughout the session.
- Hand out the poker cards. Give each player an identical set of numbered cards. We recommend using the Fibonacci sequence — 0, 1, 2, 3, 5, 8, 13, 21, etc. (To read why this sequence is so effective for estimating, see Mike Cohn of Mountain Goat Software's explanation.) And by the way, if you can't meet in person and are planning as a distributed team, then you can try planningpoker.com as a way to conduct your session remotely. 😃
- Read a user story. The moderator reads the team members a story from the sprint. They should provide as much detail and context as possible to help the team estimate the work involved.
- Discuss the story as a group. First, let the team ask any clarifying questions about the user story that was just read. Then, open the floor for discussion — each team member can describe what it will take to get the story done, any dependencies blocking the work, and who on the team might need to be involved in its effort.
- Play cards. Now, it's time to play the game. Each team member submits a card (face down!) to the moderator. When all the playing cards are submitted, the moderator reveals what each one estimates. In an ideal world, all of the numbers match! This means there is perfect team consensus about the effort required for that sprint item and you can move on to the next one.
- Discuss and estimate again. Most likely, there will be some difference in the initial estimates. This gives each team member a great opportunity to provide support for why their estimates were either higher or lower than the others. Then, you can do another round of submitting and revealing cards to see if there is further consensus. Tip: Let the moderator decide when to end the round. Remember, you don’t need a perfect story point consensus for every user story.
You did it! Your sprint is planned, and the entire team gained a shared understanding of how each member perceived the effort and work needed to get each user story done.
The benefits of planning poker agile estimation
As an agile estimating and planning technique, planning poker has its pros:
- It encourages collaboration. As a cross-functional team, it's important that each team member has a voice during the estimation process. As each estimator provides their perspective on a user story, the group better understands how they arrived at their conclusion.
- It drives consensus amongst your entire team. With each round of planning poker, the team’s estimates are more likely to converge.
- It has documented merit as a more accurate way to estimate (versus a single person providing the estimates).
In a study published by ScienceDirect, planning poker was used to estimate half of the work of a software project. There were two discoveries. First, planning poker estimates were statistically higher than individual estimates. Second, the poker estimates turned out to be more accurate than the individual estimates for the same tasks.
Planning poker for roadmap planning
Planning poker is a fun and effective way to gain an accurate estimate for your product backlog items. But, why not also use it for strategic planning sessions like roadmap planning?
In our definitive guide to product roadmaps, we discuss how roadmaps focus on big-picture, customer-centric themes, as opposed to individual features. We also highlight that developing your product roadmap should be a collaborative process (just like sprint planning) and should involve multiple stakeholders.
So, go back to the steps above. Think about how you can use planning poker cards to get your relevant stakeholders to estimate the relative size of each customer theme in your product roadmap. It will be a fun way to get a big-picture consensus of your organization's product vision.
Grouping your themes
Planning poker is a collaborative way to get the whole team to help estimate the work involved in a user story. It drives consensus and tends to be more accurate.
If you use Jira to conduct your sprint planning meetings, you already have a tool that organizes your user stories and product backlog. As you try planning poker in your next product roadmap planning meeting, give Easy Agile User Roadmaps for Jira a look. It provides the ability to group Jira items into themes that your stakeholders can easily see. Happy playing!
WorkflowThe Ultimate Agile Sprint Planning Guide [2024]
How do you feel when someone mentions “planning”? Do you look forward to the opportunity or does the thought of making a plan send you running for the hills?
Sprint planning is a crucial part of the agile sprint cycle. It helps you and your team align around common goals, and sets you up for a successful sprint. Even if planning isn’t one of your strengths, the good news is that you can practice and get better over time with the help of some good advice.
We’ve combined our best sprint planning tips into an ultimate guide to agile sprint planning, with everything you need to run efficient and effective planning meetings.
What is agile sprint planning?
Agile sprint planning is a key ceremony in the agile sprint cycle. It signifies and prepares the team for the start of the sprint. Without this planning, there is a very real risk that the team would lack focus and fail to align on what is most important.
Effective agile sprint planning has three key parts; a sprint goal, an understanding of team capacity, and a prioritized set of backlog items. Each element depends on the other for success.
The idea is to align your team around a goal for the next sprint by agreeing on a set of backlog items that are achievable within the sprint and contribute to reaching the sprint goal. Gaining focus and clarity on what you plan to achieve will help your team to work better together and to deliver on objectives.
It is best to start with an agreed sprint goal. You can then prioritize work on the specific set of backlog items that your team has the capacity to complete, and that will contribute to making your sprint goal a reality.
How sprint planning fits within the Scrum process
We’re big fans of the Scrum process, and it’s hugely popular with many software development teams. While agile sprint planning can take many forms within the different agile methodologies, for the purposes of this guide, we’ll focus on agile sprint planning within the Scrum framework.
If your team doesn’t follow Scrum don’t worry — you’ll still find value in our preparation tips, meeting guide, mistakes to avoid, and sprint planning resources.
💡 Learn more: What's the Difference Between Kanban vs. Scrum?
Scrum roles: The people
There are three main roles within a Scrum team.
- Product Owner
- Scrum Master
- Development team
The Product Owner puts in the work upfront. They help prioritize the product backlog items and decide which should move to the sprint backlog. These important decisions guide the goals of the sprint and determine the tasks the team will tackle over the next sprint.
The Scrum Master acts as a guide, they lead meetings that help ensure that the Scrum framework is followed throughout the sprint to keep the team on track. The Scrum Master helps the team get the most out of the entire Scrum process and each individual Scrum ceremony.
The development team is made up of the various people who will complete the work agreed upon during sprint planning.
There are others that you might refer to during sprint planning, such as stakeholders, users, and customers. While these aren’t technically Scrum roles, they play a critical role in product development. Stakeholders should be brought into the process early and often, and customers should always be top-of-mind when making any development decisions. Some teams find User Personas to be a valuable way of keeping user value in focus.
Artifacts: What gets done
Artifacts are the things to get done — different breakdowns of what the team hopes to accomplish:
- Product backlog
- Sprint backlog
- Increments
Product backlog items are the tasks the team believes they need to accomplish in order to complete a product or specific improvement of a product. It is the big master list of everything that the team thinks they need to accomplish. The product backlog is flexible and iterative, and it will evolve as the team learns more about the product, stakeholder feedback, and customer needs.
The sprint backlog is more focused than the product backlog. The product owner moves the most important backlog items from the product backlog to the sprint backlog at the beginning of each sprint based on current issues, priorities, and customer needs. The team aims to complete all of the sprint backlog items over the course of the sprint.
An increment is a concrete stepping stone toward reaching the Product Goal. An increment must be verified as usable in order to provide value, which means that any work completed cannot be considered part of an increment unless it meets the Definition of Done (an agreement among the team of what “done” means). This is a formal description of the state of the increment when it meets the quality standards required of a product. Once the work completed satisfies the agreed Definition of Done, you gain an increment.
Scrum ceremonies: Where Sprint Planning fits
There are a number of ceremonies in Scrum that occur each sprint. This is where sprint planning fits within the Scrum process.
- Sprint planning
- Daily scrum (or standup)
- Sprint review
- Sprint retrospective
💡 Learn more: Agile Ceremonies: Your Guide to the Four Stages
Sprint planning is the first Scrum ceremony — it prepares the team for the sprint. The planning session sets everything into motion, aligning the team on what’s most important for this sprint. This is when decisions are made and key backlog items are moved from the product backlog to the sprint backlog.
The second ceremony repeats every day of the sprint. Daily standups bring the team together to discuss progress and blockers that might be getting in the way. By getting the concerns out in the open early, the team can avoid the frustration of delays and ensure work continues to flow.
The final two ceremonies happen at the end of the sprint. For the sprint review, the team comes together to determine the success of the sprint based on the “Done” work completed. It’s also a chance to bring in stakeholders to gather feedback on what's been accomplished so far. The sprint review ensures customer insights are always top-of-mind, stakeholders continually see progress, and guarantees the product never strays too far from what the stakeholders are looking for.
The sprint retrospective gathers critical insights from team members about how the sprint went. What went well, what didn’t go so well, and what could be improved upon for next time? These valuable insights are what makes Scrum agile — the team is always thinking critically about the process and looking for ways to improve the work and how they work together.
We’ll talk about these ceremonies in more detail below when we discuss what happens after the sprint planning meeting.
The benefits of agile sprint planning
Agile sprint planning is a powerful meeting that should not be overlooked or underestimated. It is an opportunity to:
- Bring the whole team together and align around common goals
- Set context by starting the sprint with clear priorities
- Identify potential roadblocks before they occur
- Bring stakeholder feedback into the planning process
- Learn from previous sprints by considering sprint review and retrospective insights
- Consider team capacity and adjust accordingly to ensure that goals are achievable and that the team isn’t overcommitted in the upcoming sprint
- Account and plan for dependencies that may impact the flow of work.
How to prepare for a sprint planning meeting
We know we said that a sprint begins with sprint planning, but there are actually a few important steps you must take in order to prepare for the planning session. Unfortunately, you do need to do a little planning for the planning meeting.
Backlog refinement
Backlog grooming or refinement keeps your backlog healthy, up-to-date, and ready for sprint planning. A refined backlog will help ensure your team’s planning time is used efficiently and effectively since you won't have to waste time adding details to the backlog that could have been completed in advance before everyone came together.
The product manager should groom the backlog a few days before the sprint planning meeting to make sure it’s ready.
Tips for maintaining a healthy backlog:
- Ensure stories are in order of priority
- Prioritize items that bring the customer the most value
- Add detail to the highest-priority backlog items
- Split any user stories that are too big
- Delete any user stories that aren’t relevant anymore
- Create new user stories based on new or clearer needs
- Add items based on new stakeholder feedback
- Make adjustments based on bug fixes
- Assign more accurate estimates
💡 Learn more: Essential Checklist for Effective Backlog Refinement (and What To Avoid)
Be consistent
A consistent meeting time that’s scheduled well in advance will ensure that the entire Scrum team keeps the time slot open. Book your sprint planning meeting on the same day and at the same time every sprint so that no one forgets or double books.
Sprint planning is not a meeting to be shuffled around, delayed, or ignored — sprint planning meetings are essential to the success of every sprint. Ask your team about a specific, recurring time to meet, and ensure it works for everyone.
How to run a sprint planning meeting
While the agile method is flexible and collaborative, it isn’t chaotic; everything needs to begin with a plan.
1. Stick to a set sprint planning meeting duration
As with any kind of meeting, the team can be easily sidetracked without a timebox. After all, talking about the work that needs to be completed is often easier than actually completing it. It’s the Scrum Master’s job to keep the team on track and make sure the time limit isn’t exceeded.
Go into the sprint planning meeting well-prepared; a clear agenda and a well-refined backlog mean your team can get straight to planning.
Set a realistic timebox for the meeting and stick to it. We recommend that you avoid scheduling more than 2-3 hours for a sprint planning meeting, but as you become more skilled in sprint planning, you’ll better understand the length of time that works for you and your team.
2. Use estimates to make realistic decisions
You want your team to be as productive as possible, but overloading them can actually hinder productivity and focus. Unreasonable expectations are demotivating and overcommitted team members are more likely to make mistakes.
You need to understand the effort and time it will take to complete the goals you set out to accomplish for each sprint. Agile estimation techniques and story points provide a better understanding of team capacity, individual capacity, and what a reasonable workload looks like. Reasonable and realistic goals will help your team stay motivated and support a consistent flow of work.
3. Define clear goals and outcomes
What does the team aim to accomplish between now and the end of the sprint? Set clearly defined goals and outcomes that everyone understands. Do your goals align with what you learned from past sprints? Do they align with customer needs? Does everyone agree on what the next sprint will (roughly) look like?
Don’t assume that everyone is on the same page. Ask questions and encourage your team to speak up if anything is unclear. It’s better to clear up discrepancies or misunderstandings now rather than once the work begins.
Setting sprint goals effectively involves following the SMART framework, a well-regarded strategy in project management and goal-setting across various industries. The acronym SMART stands for:
- Specific: Clearly define what you aim to achieve. Avoid vague goals by pinpointing precise outcomes.
- Measurable: Establish criteria for measuring progress. This helps in tracking accomplishments and identifying areas that need adjustment.
- Achievable: Aim for goals that are challenging yet attainable with the resources at hand. Overambitious targets can demoralize a team if not realistic.
- Relevant: Ensure that each goal aligns with the broader objectives of the project. Irrelevant tasks can divert energy from what's truly important.
- Time-bound: Set a clear deadline to maintain urgency and focus. Sprint goals must coincide with the sprint’s limited timeline to ensure timely completion.
In practice, applying the SMART framework to sprint goals means your team is synchronized and focused on priorities that drive the project forward efficiently. By keeping goals relevant and achievable within the sprint's timeframe, you avoid misallocation of efforts and ensure progress is aligned with overall project ambitions.
Post your sprint goal somewhere that is easily accessible so that the team can refer back to it throughout the sprint.
💡 Learn more: How to Make the Most of Your Sprint Goals
4. Decide what it means to be ‘done’
What does “done” mean for any given backlog item, increment, product issue, or product as a whole? The team and your stakeholders need to agree on what done looks like in order to set realistic goals that meet the expectations of everyone involved.
As you set goals and choose which backlog items to complete for the next sprint, be clear about what it means to meet and complete the goals you want to accomplish.
5. Align sprint goals with product goals
Sprint goals should always align with your broader product goals. Your sprint may take a specific direction depending on current product issues, bug fixes, or customer concerns, but it’s important to keep an eye on the big picture.
Choose backlog items with care — make sure they relate to the larger product goal and that each works in sync to move development forward. Overlooking product goals in sprint planning could mean that each sprint looks more like a random selection of to-do lists that don’t connect back to customer needs, relate to product goals, or help you reach important increments. The result will feel like a lack of progress, which risks disengaging the team and other important stakeholders, like your users.
What happens next?
Now that the planning is done, you’re ready to implement your plan and complete the work. But that doesn’t mean that team members go off and work in isolation.
Daily scrum (or stand-up)
The daily scrum or stand-up is an opportunity for a collaborative agile team to maintain progress. It should be a quick check-in at the start of each day.
The team will discuss what has been done in the past 24 hours, any roadblocks they might have hit, and what the team hopes to accomplish the next day.
This critical check-in helps the team stay on the same page, helps to ensure the continued flow of work, and keeps the team on track to achieve sprint goals.
Sprint review
A sprint review meeting takes place at the end of a sprint. It's a chance for the team to review all of the “Done” issues for that period. The sprint review determines whether or not the goal for the sprint was achieved.
It’s a chance to demonstrate shippable working product increments to the team, and also an opportunity to bring in stakeholder feedback. This feedback gives you valuable insights to assess if you’re on the right track, or need to make changes in the next sprint. The sprint review is also excellent preparation for the next backlog grooming and sprint planning session.
💡 Learn more: Introduction to Sprint Reviews
Sprint retrospective
While the sprint review looks at what was accomplished and how to move forward, the retrospective examines your processes and how the team is working together.
What did you learn during the previous sprint? While retrospectives can take many forms, the goal is to discover what worked well, what didn't go so well, and what could be improved upon next time. Your team will use the insights gathered in the retrospective to improve how you work together and deliver value to customers in the future.
💡 Learn more: 5 Steps to Holding Effective Sprint Retrospectives
Agile sprint planning mistakes
It’s easy to fall into bad habits, especially as deadlines and product launch dates approach. Avoid these common agile planning mistakes to ensure your team is always making the most of the agile methodology and the Scrum process.
Unrealistic expectations
Choosing unattainable goals sets your whole team up for failure. Failing to meet your sprint goals sprint after sprint is damaging for team motivation and morale.
Use estimates to set reasonable goals as best you can. Consider team capacity, factoring in your past knowledge of how long tasks take to complete, how the team works, and potential roadblocks that could arise along the way.
Lack of context
Your team will benefit from an understanding of how the issues they’re working on fit into the bigger picture.
Depending on the tool you’re using to plan and manage your work, it can be difficult to see the contextual detail needed to plan and work with clarity. The more items you have, the more difficult and overwhelming it will be to organize and prioritize. Use tools that allow you to add context, depth, and customer insights with clean functionality to adapt your plan to the needs of your team and stakeholders.
Neglecting your backlog
We mentioned this point when we talked about what you need to do to prepare for sprint planning. It’s worth mentioning again because it’s a common mistake.
When you go into a sprint planning meeting without a well-managed backlog, you lack the clarity you need to plan effectively. Your time is valuable, and so is the time of your team, so it should be treated with care and used effectively.
A well-managed backlog is DEEP:
- Detailed appropriately
- Estimated
- Emergent
- Prioritized
💡 Learn more: The 4 Characteristics of a Good Product Backlog
Not allowing the plan to adapt
When you plan your sprint, you’ll do everything you can to prioritize the most important tasks for the length of the sprint. It’s important to try to stick to the plan as best you can, but you also need to adapt as you acquire new information.
Be ready to make changes on the fly should you hit roadblocks or acquire new information about customer needs, concerns, or product issues.
Failing to understand stakeholders
You need to understand the goals and priorities of stakeholders to be successful. Just because you’re happy with what you’ve accomplished doesn't mean your stakeholders will too.
Ensure your stakeholders are brought into your process early and often and help them understand how you work to provide them value. Gather feedback from stakeholders regularly to ensure your goals are aligned. A good time for this is during the sprint review. Just make sure those insights are transferred over to your next planning meeting.
Not choosing tools with a customer-centric approach
Successful product development delivers what the customer needs and wants. To build for your customers, it helps to use tools for planning and work management that makes it easy to keep them top-of-mind. Incorporating user story maps and customer personas into your planning helps you and your team prioritize the work that will deliver the most value first.
💡 Learn more: 10 tips for more effective user personas
Failing to incorporate retrospective insights into planning
Retrospectives are the best thing you can do to help your team work better together. During a retrospective, you're asking your team to be open and honest about how things went over the course of the sprint so that you can learn from each other.
Failing to learn from those insights means that the collective time spent in the retrospective has been wasted, and the feedback that your team has shared is devalued.
Incorporating the learnings you gain from a retrospective into your next planning session and into the next sprint, will support your team to improve every time, helping them gain work satisfaction and deliver better outcomes.
Virtual vs. in-person sprint planning
The advantages of remote work also bring challenges for collaborative planning. No matter the way your team chooses to meet, whether virtually, in person, or a combination of both, it’s important that you choose tools that meet the needs of your team.
Tips for virtual sprint planning:
- Be really prepared - communicate plans clearly ahead of time, so that everyone has clear expectations.
- Use a video conferencing tool that allows for breakout sessions
- Set up the interactive online resources you plan to use and include links in the meeting request.
- Online discussions don’t start as naturally as they would in person, so share discussion topics ahead of time, and consider preparing some ice-breakers.
- Ensure that you’ve accounted for time differences for teams that span time zones.
- Tech issues arise no matter how much advanced planning and testing you do. Always expect the unexpected.
Tips for in-person sprint planning:
- Book a meeting room with plenty of space for your team, and consider separate spaces for breakout sessions.
- Ensure that your meeting room will accommodate a shared view of your sprint plan - do you need a wall for sticky notes, or a screen to share a digital tool?
- If some of your team members work remotely, it’s difficult to involve them in the same way, so consider how this might work for your team. They won’t be able to read a whiteboard or sticky notes as easily, so a digital solution may be best.
- If you choose to plan your sprint ‘on the wall’, be sure to nominate someone to transcribe your plan into your work management tool at the end of the planning meeting.
No matter where your planning takes place, always remember to prepare your backlog ahead of time so that you can have focused and informed discussions during sprint planning.
Additional agile resources
We’re continually adding to our content library, which is filled with resources, how-to guides, product updates, and more.
📚 Add these to your list:
- Easy Agile Podcast Ep.20: The importance of the Team Retrospective
- Easy Agile Podcast Ep.18 Top qualities of an agile leader and team
- Easy Agile Podcast Ep.16 Enabling high performing agile teams with Adaptavist
- Being agile vs doing agile
- The Ultimate Guide to User Story Mapping
- The Ultimate Guide to Buyer Personas
- The Ultimate Guide to PI Planning [2022 SAFe Edition]
Using Easy Agile to improve sprint planning
Make your sprint planning smooth and effective with Easy Agile TeamRhythm. Transform your flat product backlog into a dynamic, flexible, and visual representation of the work to be done. Seamlessly integrated with Jira, with TeamRhythm you can:
- View your Jira stories, tasks, and bugs in context, aligned beneath their epics on the story map
- Drag and drop Jira issues from the backlog into a sprint
- Create new issues right on the story map
- Estimate issues on the story map, and gauge capacity with story point totals in each sprint swimlane
- Publish the sprint goal on each sprint swimlane, so it’s always top of mind
- Use filters to focus on the stories and issues that are most important now
- Group epics by a third level of hierarchy, to easily see how the work in focus contributes to the bigger picture
Easy Agile TeamRhythm also supports team retrospectives, with flexible and intuitive retrospectives boards created for every sprint. You can add retrospective items right from the sprint swimlane, so you don’t forget any important points. And you can turn retrospective action items into Jira issues that can be scheduled for future sprints, so you’re always getting better at what you do, and delivering for your customers.
Thanks for reading our ultimate agile sprint planning guide! If you have any questions about this guide, our other content, or our products, reach out to our team at any time. We love hearing from you.
We’ll continue to update this guide as we gain more agile planning insights, techniques, tools, and best practices.
WorkflowThe Difference Between a Flat Product Backlog and a User Story Map
It’s one of the most common practices in agile software development; the flat product backlog. We’ve all seen them, we’ve all contributed to them, and we’ve all inevitably drowned in them.
In its simplest form, a flat product backlog is a laundry list of ‘stuff to do’ that will ultimately provide value to the customer. These actionable items are prioritised (top to bottom) in the order the value will be delivered. If a team is adopting the Scrum method the backlog is split into future sprints to provide an indication of what will be delivered and when.
Depending on the size and requirements of the organisation, the list of things to be done could be 10, 100 or 1,000 actionable items. It’s easy to see how managing the latter comes with the challenges of updating, assigning, grooming and scheduling these items.
What’s Wrong With Flat User Story Backlogs?
So far we know that flat backlogs represent a list of things to be done. This comes with its challenges, and its shortcomings were best described by Jeff Patton when he said;
We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.
After all that work, after establishing all that shared understanding, I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.
That’s what a flat backlog is to me. A bag of context-free mulch
How do you pick an item from a list, and deem it the thing that’s going to provide the most value to your customers, without that additional context?
Shortcomings of a Flat Product Backlog
- The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product
- Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does
- The flat backlog provides no context or ‘big picture’ around the work a team is doing
- A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories
- Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?
User Story Maps
A story map is a visual representation of the journey a customer takes with a product, including the activities and tasks they complete. This visualisation helps the team to focus development on providing the most value to customers and their desired outcomes.
It provides context for teams by answering the following questions:
- Why are we building this?
- Who are we building this for?
- What value will the solution provide for the customer and when?
The story map still showcases the ‘stuff to be done’, the difference here though, is the way in which this information is visualised. As you can see, rather than listing these items out, each item is contextualised under a bigger piece of work. Besides the way the information is visualised, the key difference between a flat product backlog and a user story map, is the focus on the customer journey. Let’s unpack this by breaking down the anatomy of the user story map.
What A User Story Map Achieves that a Flat Product Backlog Can’t
- Focus on Desired Customer Outcomes: the visualisation of the customer journey allows teams to identify and implement features based on customer outcomes, and track progress at a glance against a story map
- Bring the Customer Journey to Life: the transformation of the flat product backlog to a customer centric story map means teams have a better understanding of their customer journey and what their customers want and value
- Prioritising Actions Based on Value to the Customer: visualisation of the customer journey allows teams to prioritise work based on “value to customer”, resulting in better outcomes and less waste
Are you getting lost in your flat product backlog? Are you stuck in an endless development cycle, but not really sure for who or why your building features?
Easy Agile TeamRhythm
Easy Agile TeamRhythm supports User Story Mapping, sprint or version planning, backlog refinement, and team retrospectives.