Sprint Planning

At Easy Agile, we’re constantly looking for new ways to improve our products, and one of the ways we foster innovation is through Dash Days—a focused period where our team steps away from daily tasks to experiment, explore, and reimagine how our tools can better serve customers.

During our most recent Dash Days, we took a fresh look at the user interface of two of our flagship products, Easy Agile TeamRhythym and Easy Agile Programs. The goal was to enhance interaction and discoverability, so users can experience the full value of our tools without unnecessary complexity.

Here’s a glimpse into our thought process, challenges, and the exciting solutions we explored.

The challenge

As Easy Agile TeamRhythym and Easy Agile Programs have evolved, we’ve introduced powerful features designed to give users more control and flexibility. However, as new capabilities have been added, the interface has become more elaborate. For us, this presents an opportunity—an opportunity to take a step back, simplify the experience, and help users unlock more of what our products offer.

To address this, we brought people from across the business together to brainstorm how we could improve the experience in both products. Through these sessions, we identified a few core opportunities:

• Discoverability: How do we make it easier for users to find and use the powerful features built into our tools?
• Visibility: What’s the best way to surface the right information and features when users need them? 
• Consistency: How do we create a more uniform experience within and across our products to make navigation intuitive?

Armed with these insights, we then set out to explore solutions tailored to each product’s unique challenges. 

A more personalized experience with Easy Agile Programs

For Programs, we focused on three “how might we” questions to reframe our challenges into opportunities: 

1. How might we create more focus on the actions users are trying to complete?
2. How might we make navigation more intuitive and easy?
3. How might we help users with more context about where they are in the app at any given screen? 

Out of the many solutions we explored, the one that got us the most excited was the idea of an Easy Agile Programs Home Screen—a personalized dashboard designed to guide users based on where they are in their planning cycle. 

This home screen could adapt based on where users are in their journey, offering relevant guidance and actions.

• For new users, the home screen could provide clear onboarding steps and easy access to help, so they can get started quickly and confidently.
• For experienced users, it could offer insights and key actions related to their progress, so they can stay focused on what matters most. Users might even see data summarizing their accomplishments, which makes it easier to share successes with their teams.

Whether someone’s brand new to the product or deep into execution, the home screen could be a great way to guide and coach our users—helping them answer questions like, "What should I be doing next?" or "What extra value am I missing out on?". 

A more focused interface for Easy Agile TeamRhythm

For TeamRhythym, our three key “how might we” questions were:

• How might we provide more focus within the User Story Map during sprint planning?
• How might we improve the discoverability of issues without epics?
• How might we enhance the layout to highlight key features and improve overall usability? 

With these questions in mind, we explored a range of ideas to simplify sprint planning and make it easier for users to prep, plan, and review their work, whether they’re using Scrum or Kanban.

Sprint planning can sometimes feel overwhelming when you have multiple sprints competing for attention. To help users focus, so we explored the idea of introducing a focused view during sprint planning. 

• This would allow users to zoom in on a specific sprint and the backlog alone, while collapsing others. 
• Each issue would have its own row in the detailed view, and users can drag and drop either an entire row or drag individual issues to quickly rank them based on priorities.
• The sprint view will also hide epics that don’t have linked issues in the current sprint, giving users a cleaner view of what’s relevant to their current work.

We also looked at ways to enhance the User Story Map interface to bring the most useful tools and features to the forefront. By improving how key functionality is presented, we’re helping teams quickly access what they need, when they need it, enabling them to stay productive without interruption.

This way, we can create a smoother, more focused experience for teams using TeamRhythm, so they can focus on what’s in front of them without being distracted by everything else.

Your turn. What do you think?

At Easy Agile, we’re always thinking about what comes next. 

These ideas aren’t on our official roadmap just yet, but they’re the kind of innovations we’re excited to explore.

If you think these changes would improve your experience with Easy Agile TeamRhythm and Easy Agile Programs, let us know! Your feedback helps us decide what to prioritize, so we can continue building tools that truly make a difference for your teams.

‍

The seventh principle of the Manifesto for Agile Software Development is:

Working software is the primary measure of progress.

Not story points, not velocity, not estimates: working software.

Jason Godesky
Better Programming

Estimation is a common challenge for agile software development teams. The anticipated size and complexity of a task is anything but objective; what is simple for one person may not be for another. Story points have become the go-to measure to estimate the effort involved in completing a task, and are often used to gauge performance. But is there real value in that, and what are the risks of relying too heavily on velocity as a guide?

Agile estimation

As humans, we are generally terrible at accurately measuring big things in units like time, distance, or in this case, complexity. However, we are great at making relative comparisons - we can tell if something is bigger, smaller, or the same size as something else. This is where story points come in. Story points are a way to estimate relative effort for a task. They are not objective and can fluctuate depending on the team's experience and shared reference points. However, the longer a team works together, the more effective they become at relative sizing.

The teams that I coach have all experienced challenges with user story estimation. The historical data tells us that once a story exceeds 5 story-points, the variability in delivery expands. Typically, the more the estimate exceeds 5 points, the more the delivery varies from the estimate.

Robin D Bailey, Agile Coach, GoSourcing

Scale of reference

While story points are useful as an abstraction for planning and estimating, they should not be over-analyzed. In a newly formed team, story points are likely to fluctuate significantly, but there can be more confidence in the reliability of estimations in a long-running team who have completed many releases together. Two different teams, however, will have different scales of reference.

At a company level, the main value I used to seek with story points was to understand any systemic problems. For example, back when Atlassian released to Server quarterly, the sprints before a release would blow out and fail to meet the usual level of story point completion. The root cause turned out to be a massive spike in critical bugs uncovered by quality blitz testing. By performing better testing earlier and more regularly we spread the load and also helped to de-risk the releases. It sounds simple looking back but it was new knowledge for our teams at the time that needed to be uncovered.

Mat Lawrence, COO, Easy Agile

Even with well-established teams, velocity can be affected by factors like heightened complexity with dependencies scheduled together, or even just the average number of story points per ticket. If a team has scheduled a lot of low-complexity tickets, their process might not handle the throughput required. Alternatively having fewer high-complexity tickets could drastically increase the effort required by other team members to review the work. Either situation could affect velocity, but both represent bottlenecks.

Any measured change in velocity could be due to a number of other factors, like capacity shifting through changes in headcount with team members being absent due to illness or planned leave. The reality is that the environment is rarely sterile and controlled.

Relative velocity

Many organizations may feel tempted to report on story points, and velocity reports are readily available in Jira. Still, they should be viewed with caution if they’re being used in a ‘team of teams’ context such as across an Agile Release Train. The different scales of reference across teams can make story points meaningless; what one team considers to be a 8-point task may be a 3-point task for another.

To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better.
…
So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.

Ron Jefferies
Co-Author of the Manifesto for Agile Software Development
Story Points Revisited

Seeking value

However, story points are still a valuable tool when used appropriately. Reporting story points to the team using them and providing insights into their unique trends could help them gain more self-awareness and avoid common pitfalls. Teams who are seeking to improve how they’re working may wish to monitor their velocity over time as they implement new strategies.

Certainly, teams working together over an extended period will come to a shared understanding of what a 3 story point task feels like to them. And there is value in the discussion and exploration that is needed to get to that point of shared understanding. The case for 8 story points as opposed to 3 may reveal a complexity that had not been considered, or it may reveal a new perspective that helps the work be broken down more effectively. It could also question whether the work is worth pursuing at all, and highlight that a new approach is needed.

The value of story points for me (as a Developer and a Founder) is the conversations where the issue is discussed by people with diverse perspectives. Velocity is only relatively accurate in long-run teams with high retention.

Dave Elkan, Co-CEO, Easy Agile

At a company level, story points can be used to understand systemic problems by monitoring trends over time. While this reporting might not provide an objective measure, it can provide insights into progress across an Agile Release Train. However, using story point completion as a measure of individual or team performance should be viewed with considerable caution.

Story points are a useful estimation tool for comparing relative effort, but they depend on shared points of reference, and different teams will have different scales. Even established teams may notice velocity changes over time. For this reason, and while velocity reporting can provide insights into the team's progress, it must be remembered that story points were designed for an estimation of effort, rather than a measure. And at the end of the day, we’re in the business of producing great software, not great estimates.

Looking to focus your team on improvement? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives linked to your agile board in Jira, to improve your ways of working and make your next release better than the last. Turn an action item into a Jira issue in just a few clicks, then schedule the work on the user story map to ensure your ideas aren’t lost at the end of the retrospective.

Many thanks to Satvik Sharma, John Folder, Mat Lawrence, Dave Elkan, Henri Seymour, and Robin D Bailey for contributing their expertise and experience to this article.

Story points can be a little confusing and are often misunderstood. Story points are an important part of user story mapping, and many agile teams use them when planning their work. But they aren't as simple as adding numbers to tasks or estimating how long a job will take.

Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them differently.

So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.

What are user story points?

Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. You assign a number to each user story to estimate the total effort required to bring a feature or function to life.

When to estimate story points

User stories can be estimated during user story mapping, backlog refinement, or during sprint planning.

Once a user story has been defined, mapped to the backbone, and prioritized, it's time to estimate the story points. It is a good idea to work with your team to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching. Collaborating on story point estimation will also help you spot dependencies early.

It is best to assign story points to each user story before you sequence them into releases or sprints. This allows you to assess the complexity, effort, and uncertainty of each user story in comparison to others on their backlog, and to make informed decisions about the work you decide to commit to each sprint or release.

How to estimate user story points

When estimating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:

• How complex is the work?
• How much work is needed?
• What are the technical abilities of the team?
• What are the risks?
• What parts are we unsure about?
• What do we need in place before we can start or finish?
• What could go wrong?

Tip: If you're having trouble estimating a story or the scope of work is overwhelming, you might need to break your story down into smaller parts to make multiple user stories.

What is a story point worth?

This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).

Here’s how it works:

• Each story is assigned a certain number of story points
• Points will mean different things to different teams or organizations
• 1 story point for your team might not equal the same amount of effort involved in 1 story point for another team
• The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another
• 2 story points should equal double the effort compared to 1 story point
• 3 story points should equal triple the effort compared to 1 story point… and so on

The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint.

Estimating story points for the first time

Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.

Start by choosing stories of several different sizes:

• One very small story
• One medium sized story
• One big story

...a bit like t-shirt sizes.

Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.

The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.

Over time, you and your team will find estimating user stories becomes easier as your shared understanding of the work develops. This is where story points become most valuable, helping your team align expectations and plan more effectively.

Make estimation easier

An app for Jira like Easy Agile TeamRhythm makes it easy to see team commitment for each sprint or version, with estimate totals on each swimlane.

Using the Fibonacci sequence for story point estimation

Some teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).

This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach a consensus much more quickly.

This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.

But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.

Using story points to estimate velocity

After some time working together most teams will have a good idea about how much effort is involved in each story point.

Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.

But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.

You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.

For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.

Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.

As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.

Over time, your estimations should become more accurate.

Using Story Points in Scrum, Kanban, and Extreme Programming

Story points are central to estimation and planning processes in many agile methodologies. Scrum and Extreme Programming (XP) rely heavily on story points to gauge the effort and complexity of user stories.

Scrum teams use story points during sprint planning to decide which tasks to include in the upcoming sprint, encouraging discussion that leads to shared context and understanding of the work.

Extreme Programming on the other hand, uses story points to assess the size of features, enabling teams to prioritize and allocate resources effectively. Teams using Kanban can benefit from story points by using them to set work-in-progress limits and optimize the flow of tasks across the board.

While the specific practices may differ, story points can help encourage team collaboration and a more predictable flow of work.

The sprint goal is a key aspect of any sprint, and it should be front and center throughout your two-week process. The goal ensures the team is aligned on a clear purpose for the sprint, and, if done well, the goal inspires the team to stay on track throughout the entirety of the sprint.

So, what makes a good sprint goal, and how does the sprint goal fit within the framework of a sprint? In this post, we’re going to race (or should we say sprint 😉 ) through a recap of the Scrum process, followed by a list of five critical elements of an effective sprint goal. You’ll learn how to best create, manage, and follow through on your sprint goals for a successful sprint every two weeks.

An overview of the Scrum process

We’re big fans of Scrum! Need a little refresher? Here’s how the Scrum process works and where the sprint goal fits into the whole picture.

Scrum is an agile framework used primarily by software development teams that provides team members with a streamlined workflow to meet stakeholder and customer needs. The Scrum workflow has four meetings (also known as ceremonies), which all have a distinct purpose. This structure means team members can easily support each other by sharing, tracking, and enhancing deliverables.

The Scrum framework divides work into repeating two-week sprints where a set amount of work — the sprint goal — is completed. Each Scrum begins with a sprint planning meeting, and during this time, the product owner defines the sprint goal. They choose which tasks will move from the product backlog to the sprint backlog to be completed over the following two-week sprint.

Product backlog items represent the whole picture of what needs to be accomplished before completing or releasing a product. Sprint backlog items are what the team will (hopefully) accomplish over the course of the sprint.

The Scrum Master acts as a Scrum guide who leads the team through the meetings and steps of the Scrum process. Throughout the sprint, the Scrum team meets for a daily Scrum to check in with one another and report on what work was completed over the previous 24 hours.

At the end of the sprint, a sprint review and sprint retrospective help the team gather feedback from stakeholders and improve upon their processes before the next sprint begins. The entire process repeats again with sprint planning and continues to repeat until the product or project is complete.

Easy Sprint Planning:

Drag items directly from your backlog onto your TeamRhythm User Story Map. Inline edit story summaries and story point estimates. Display your sprint goal on each sprint swimlane.

TRY: TEAMRHYTHM SANDBOX DEMO

What makes a good sprint goal?

The sprint goal keeps the team focused and aligned on what everyone is trying to accomplish for each sprint. It’s an extension of the overall product or project goals, but the sprint goal can zero in on key components the team wants to tackle for that specific sprint.

What makes a good sprint goal? Let’s find out.

1. The goal is achievable

The objective of the sprint needs to be achievable within the sprint’s allotted time frame. Generally, in a Scrum framework, the team is time-bound to two weeks.

As new information is gained and other impediments occur, there’s always a chance the sprint goal won’t be met. But that shouldn’t stop you from setting achievable goals. When a team continually fails to meet the goals of the sprint and the project, morale and enthusiasm will decline.

It’s crucial that sprint goals are manageable within the allotted time of the sprint. Sprint goals can become too large when a team tries to accomplish too many different components at once or if too much of the product backlog makes it into the sprint backlog. Rather, take a reasonably achievable workload out of the product backlog to form the sprint backlog. Otherwise, you’ll end up with one daunting overall list and no clear direction for each sprint.

2. The team understands the definition of done

The clearer the sprint goal, the better. You need to clearly define the goals of the sprint and what it means to be done. How will the team know if they achieved the desired outcomes? What does “done” look like? Does everyone agree on this definition for every given task and the overall goals of the sprint?

Your goals need to be measurable to limit ambiguity, subjectivity, or conflicting opinions around the success of the sprint.

When a team is aligned, and everyone understands what needs to be accomplished, decision-making improves, and each aspect of the Scrum team can work harmoniously toward the same aims.

3. The sprint goal is meaningful to the team

Beyond knowing what the team hopes to accomplish over the course of each sprint, the team needs to understand the reasoning behind the sprint goal.

Make sure everyone understands why they are working towards a specific sprint goal. What meaning does the sprint goal have? Ideally, the meaning of the sprint goal will relate back to stakeholder needs, the customer journey, or the user experience of your product.

Visualize and prioritize the work that will deliver the most value to your customers

Easy Agile TeamRhythm

TRY NOW

4. The sprint goal aligns with the overall product goals

The sprint goal can zero in on a specific aspect of product development, but it should still connect to the overall product goals.

While creating sprint goals, ensure the overarching product vision isn’t lost or ignored. Every sprint, while specific to its own set of goals, should work toward accomplishing your product goals.

5. The sprint goal is visible throughout the sprint

The sprint goal can’t be a “set it and forget it” aspect of your sprint. It should be visible to the team the entire time, and the team needs to continually check in on the goal to ensure they’re on track to achieve it.

The shared goal should be front and center of daily Scrum meetings. If possible, display the sprint goal for everyone to see. As you accomplish backlog items and work through the sprint, continually reference the sprint goal and the progress you are making toward it. How likely are you to achieve the sprint goal considering the time you have remaining in the sprint? What might be standing in the way of achieving this goal?

During the sprint retrospective, you should discuss the success or lack of success the team made on the sprint goal. What went well and contributed to your success? What didn’t go so well that you could change or do differently for the next sprint?

With Easy Agile TeamRhythm, each scrum board in Jira will have an associated User Story Map.

Throughout the sprint, the team can refer to the User Story Map to make sure they’re on schedule, coordinate dependencies, and keep sight of the big picture.

TAKE A PRODUCT TOUR

A customer-centric approach

Let’s recap a few of the most important factors to remember when establishing and following through on your sprint goal:

✅ Ensure the goal is achievable.

✅ Ensure the team understands the definition of done.

✅ Ensure the sprint goal is meaningful for the team.

✅ Ensure the sprint goal aligns with the overall product goals.

✅ Ensure the sprint goal is visible throughout the sprint.

Thanks for sticking with us and utilizing the Easy Agile blog. We’re passionate about helping teams work better with agile. We have a suite of Jira apps designed to keep the customer top-of-mind through every step of the development process.

Looking for a tool to streamline your sprint planning sessions? Check out Easy Agile TeamRhythm, which transforms the flat product backlog into a meaningful picture of work.

The sprint planning meeting helps agile teams plan and get on the same page about each sprint. It’s an opportunity to decide on prioritization based on the product vision, issue urgency, stakeholder feedback, and knowledge from the previous sprint.

The goal of the meeting is to determine which backlog items should be tackled during the upcoming sprint. The team, guided by the product owner and Scrum Master, decide which items from the product backlog should be moved to the sprint backlog for hopeful completion over the coming weeks (sprint duration).

Sprint planning plays a critical role in the Scrum process. The meeting ensures teams enter a sprint prepared, with work items chosen carefully. The end result should be a shared understanding of sprint goals that will guide the next sprint.

While sprint planning should occur before any type of sprint, for the purposes of this article, we will focus on sprint planning sessions for Scrum teams. Continue reading to learn our top tips for a successful sprint planning meeting. 🎉

How does the sprint planning meeting fit into the Scrum framework?

Scrum is a hugely popular agile methodology used in product development. The process involves a series of sprints that are improved upon and adjusted based on continual feedback from customers, stakeholders, and team members.

The sprint planning meeting sees the entire team comes together to decide what work they hope to complete over the upcoming sprint. The product owner helps decide which priority product backlog items move to the sprint backlog. This is an incredibly important phase that guides the team’s goals over the next two weeks.

The Scrum Master acts as a Scrum guide. They help the development team stay on track in each sprint, ensuring everyone gets the most out of the process. The Scrum team works together to complete the amount of work decided on during sprint planning. To ensure everyone remains on track and on the same page, daily stand-ups are held each day. This provides an opportunity for team members to address any issues or potential bottlenecks that could keep work from running smoothly.

Following the sprint, a sprint review takes place, which gives stakeholders an opportunity to provide feedback. Finally, a sprint retrospective meeting gives the team an opportunity to assess and improve upon their process. The Scrum concludes and begins again with another sprint planning meeting.

Here are some tips to make sure each sprint planning meeting sets you up for success:

1. Reserve the same time for sprint planning ⏰

Book your sprint planning meeting on the same day and at the same time every two weeks to ensure your entire team keeps that time slot available. Sprint planning is vital to the success of each sprint — it’s a meeting that shouldn’t be shuffled around.

Pick a time that works for everyone involved, asking for feedback from your team about when is best. Schedule the meetings well in advance in everyone's calendar so that no one forgets about it or books other engagements.

2. Set a sprint planning meeting duration and stick to it ⏳

Sprint planning is important, but that doesn’t mean it should take forever. Set a time limit for your meeting, and do your best to stick to it. If you are well prepared with an agenda and refined backlog, you should be able to get straight to planning.

We recommend scheduling no more than 2-4 hours for sprint planning. Let the Scrum Master be in charge of ensuring the team stays on track and completes planning in the allotted time.

3. Complete backlog refinement before sprint planning begins 📝

Complete your backlog refinement ahead of your sprint planning meeting. Otherwise, you will spend far too much time adding details, estimating, or splitting work.

The sprint planning meeting should be reserved for planning and goal setting. While the backlog shouldn’t be set in stone, it should provide team members with enough details to move forward with planning instead of refinement.

4. Incorporate stakeholder feedback from the sprint review 😍

What insights did stakeholders share throughout the sprint or during the sprint review? You are designing this product for them, so incorporating their feedback is crucial to the end result.

Make sure every decision is based on customer needs. After each sprint, share your product goals and sprint goals with your stakeholders and adjust per their feedback.

5. Incorporate sprint retrospective insights 💡

Sprint retrospectives are a critical part of the agile process, providing a time for the team to discuss how they can improve. There are lessons to be learned every time you complete a sprint or iteration. Agile continually takes what a team learns and turns those experiences into actionable improvements. So, ignoring these lessons would be very un-agile of you. 🤔

How did the last sprint go? Was each team member satisfied with the process, and what was accomplished? What changes did your team decide would make the next sprint more effective? Use these insights to make each sprint better than the last one.

6. Clearly define what success looks like ✅

Set clearly defined goals, objectives, and metrics. What is the definition of done? How will the team know if they are successful? You should leave the sprint planning meeting with a clear idea of what needs to get done and what success looks like.

7. Use estimates to make decisions based on team capacity 📈

Overloading your team or any individual beyond their capacity does far more harm than good. The team will be more likely to make mistakes, and morale will diminish as goals remain consistently out of reach.

Use agile estimation techniques and story points to better understand workload and capacity. How much work and effort is needed to accomplish your goals? Ensure you set realistic and reasonable goals based on your best estimations.

8. Align sprint goals with overall product goals 🎉

Ensure you have a goal for the sprint and that all backlog items relate to the end goal. Your sprint goals should work alongside your overall product goals.

Failing to prioritize your objectives can result in a random selection of to-dos. Completing disconnected backlog items will still get work done, but it will result in unexpected outcomes and a low sense of accomplishment for the team. Each backlog item should be chosen with a clear purpose that relates to your product and sprint goals.

9. Leave room for flexibility 💫

Any agile methodology is flexible by nature, and Scrum is no exception. If there isn’t room for flexibility, something has gone seriously wrong.

It's important to acknowledge that not everything will always go to plan. You will continually find new information, stakeholder insights, and dependencies that the team will need to adjust to along the way. Ensure the team understands they need to be flexible and that they are supported throughout each sprint.

Sprint planning made easy

The effectiveness of sprint planning can make or break the coming week for a Scrum team. It’s important for the development team to take the necessary time to prepare for each upcoming sprint. This means going into the meeting with clear goals, objectives, stakeholder feedback, and a refined backlog.

Make the most of your sprint planning and do it with ease using Easy Agile TeamRhythm. Transform your flat product maps into dynamic, flexible, and visual representations of the customer journey. Story points will help your team make decisions and account for capacity while keeping the customer top-of-mind.

Learn more about the benefits of user story mapping and read our ultimate guide to user story maps.

It’s time to get things done and hand over the project to the programmers. But before they get their hands dirty, someone must plan the Scrum sprint or iteration. The Sprint Planning meeting is one of Scrum’s ceremonies, and it's the sprint's opening event. 🎬

Let's walk you through the event and explain how to prepare and hold one successfully. You'll also learn who participates in Sprint Planning and why the meeting is so important.

What's a Sprint Planning meeting?

Sprint Planning is a Scrum meeting. It kicks off a sprint, so it occurs on the first day of a new sprint. If applicable, it should occur after the Sprint Review and the Sprint Retrospective from the previous iteration.

Sprint Planning aims to decide the deliverables for the upcoming sprint and define a plan to develop the work.

The entire Scrum Team (the Product Owner, the Scrum Master, and the Development Team) collaborates during Sprint Planning.

Can you imagine a successful project without planning? 🙅 We can't either, so we don’t start a Scrum sprint without planning it.

To plan a Scrum sprint, you need to decide:

• The sprint's duration — remember that a sprint is a timebox
• The sprint goal, which is its purpose and represents the product increment's value to the customer
• The work that the Development Team can complete during the sprint, what work items the team should do first to achieve the sprint goal, and how long they should take considering the team's capacity

Additionally, Sprint Planning should motivate the team and set realistic expectations.

By the end of the Sprint Planning meeting, the team must produce the following outcomes:

• A shared understanding of the sprint goal. This goal is the guideline for evaluating the Development Team's work once the sprint is over.
• The Sprint Backlog. This artifact represents the conversation between the Development Team and the Product Owner on the to-do work. It's the result of a balance between customer value and development effort.

Now, each Sprint Planning meeting requires some preparation. Read on about who should do it and what it entails.

How do you prepare for Sprint Planning?

The Product Owner should follow these steps to set the foundation for successful Sprint Planning:

• Combine the output of the previous Sprint Review, feedback from stakeholders such as management and customers, and the product vision
• Update and, if necessary, refine the product backlog
• Know the customer value that the development team needs to create in an increment

So, once all the preparation is over, it's time for the Sprint Planning meeting to take place.

How should the meeting go?

1. The Product Owner indicates the Product Backlog items — and corresponding priorities — that they consider the next sprint's best candidates. Items can be user stories, tasks, or bugs. The Product Owner proposes those items according to customer value and product vision.
2. Based on effort estimates and the Product Owner's proposal, the development team selects the product backlog items to work on during the current sprint. By promoting those items to sprint backlog items, developers agree on the sprint goal with the Product Owner.
3. Although optional, the team might discuss dependencies between items and who should work on each one of them.

Very few steps, right? However, some practical actions should add on to these steps. Discover what those actions are below.

How do you execute a successful Sprint Planning meeting?

1. Limit the meeting's duration. ⏳ Sprint Planning shouldn't take longer than 1-2 hours per sprint week. That means the meeting shouldn't take more than 2-4 hours for a two-week sprint.

2. Let the Scrum Master be the guardian of time. They're the ones responsible for ensuring that the meeting happens within the defined timebox.

3. Hold the meeting on the same day and at the same time every time. 📅 Team members can be quite busy and have full agendas. That's why reserving a slot in every participant's agenda is a good practice.

4. Define valuable, clear outcomes. 🎁 Those, together with a clear sprint backlog, increase the Development Team's motivation. Producing the right outcomes is pure satisfaction, and a clear work plan is the recipe to achieve that.

5. Make sure that the Scrum Master guarantees these things. First, that the conversation between the Development Team and the Product Owner is fruitful. They should all agree on the sprint goal. Second, that the developers make good choices when moving product backlog items to the sprint backlog. Selecting an item that is feasible for the sprint duration, team capacity, and workload is a good choice.

It might seem easy, but this is not all there is to do during Sprint Planning. There's a bunch of things to avoid.

If we were to give you some advice...

Make effort estimates against the development team's capacity. To decide on the amount of work that the team can accomplish in a sprint, consider the team's capacity. (And remember, estimates are just that — estimates.) Developers consider their previous experience, yet each sprint is unique and might change over its course. However, considering team capacity improves the accuracy of effort estimation. Additionally, story points might help the team with effort estimation.

Consider that the development team's ability to estimate should improve over time. Therefore, the team should not critique less accurate effort estimates after the sprint. Otherwise, the team will take much longer to estimate or provide much bigger estimates next time.

Don't try to plan every single thing during Sprint Planning. Leave the idea of coming up with the most complete, perfect Sprint Backlog ever at the front door. After all, Scrum is all about flexibility, and "Better done than perfect." So, a Sprint Backlog that’s complete enough to get developers started is just what it needs to be. Remember that solving complex problems requires a learn-by-doing approach, which turns planning into an equally complex job.

Figure out a realistic expectation for the sprint's outcome. Setting unrealistic expectations for the increment that the development team can produce over a sprint is not a good idea. It might make developers frustrated that they couldn't deliver, which can seriously affect their motivation and performance. On the other hand, realistic expectations set the team for success and a sense of accomplishment. Besides, they facilitate the conversation between the developers and the Product Owner so they can agree on the sprint goal.

Have a well-refined product backlog. It must be detailed enough to allow the Development Team to understand what the work items are about. You don't want to waste precious Sprint Planning time splitting work items into a maximum of one per day. Define and follow a backlog refinement process and ensure that Product Backlog items meet your definition of ready.

Propose a clear sprint goal. 🎯 The Product Owner must be very clear on the expected customer value for the increment. Otherwise, the development team might choose a set of product backlog items that don’t relate to one another. The result could be unexpected outcomes and a low sense of accomplishment.

Clarify the definition of done with the Development Team. Knowing what work done means in the current sprint helps the developers meet the expectations. That's because they can better understand what to do to create the increment. Also, a clear definition of done makes the Development Team more confident when estimating effort.

Strong Sprint Planning makes your project stronger

If you're following the Scrum framework, Sprint Planning is not a choice. Nevertheless, if you ever feel tempted to skip it, bookmark this article and read the following. 📑

It's easier to understand the sprint goal, to-do work, and sprint outcomes with a successful Sprint Planning meeting. If the team doesn't know where it's heading and how to get there, it gets really tough to satisfy customer needs. It's equally hard to deliver your customers valuable increments if you don't organize work by priorities.

Sprint Planning is about instilling clarity and organizing work before it's too late in the iteration. It's also about involving the whole team in preparing for all the effort that a sprint demands. A note: Keep in mind that a sprint plan must fit into a sprint's timebox and consider the team capacity.

Easy Agile TeamRhythm is perfect for Sprint Planning. It's a fast, straightforward, visual, and collaborative tool that allows you to:

• Drag items directly from the product backlog onto the user story map
• Register effort estimates in user stories
• Edit story point estimates
• Prioritize user stories in each sprint by ordering them inside the respective sprint swimlane
• Analyze sprint statistics to ensure that the planned work doesn't exceed the team's capacity and the sprint goal is realistic
• Visualize what the team will deliver and when by arranging user stories into sprint swimlanes

Let us know if you have any questions about Easy Agile TeamRhythm. We highly recommend it to your Scrum project, and our customers recommend the same.

A sprint backlog is like an agile team's treasure map — checking off each item is like visiting a different place on the map. By the end of a sprint or iteration, the team will have delivered previously agreed outcomes and ultimately achieved their sprint goal. This is like getting to the ✖️ on a treasure map.

Join us as we find the answers you need to successfully complete each sprint. You'll learn about a sprint backlog’s purpose, plus who creates, owns, updates, and uses it.

What's a sprint backlog?

A sprint backlog consists of the items that need to be completed in order to get to the sprint goal. It should go into artifact during the sprint planning meeting. A sprint backlog has three parts:

• The sprint. Each sprint backlog targets a specific iteration.
• The sprint goal. This is the higher level aim for each sprint. To achieve it, the development team completes certain items from the product backlog.
• A plan. The sprint backlog represents a plan to deliver a product increment by the end of the sprint. It's organized to allow for progress tracking with to-do, in-progress, and done items, plus effort estimations and remaining workload.

The sprint backlog should always be accessible and up-to-date so that the development team understands the work and can see what is coming up next. It should also have enough detail to allow tracking work progress.

Each sprint starts with a sprint backlog, and the artifact's lifespan equals the sprint's duration. You may expect to find work items — user stories, tasks, or bugs — in it.

The sprint backlog is the development team's go-to home to find all the ideas for what to work on. At every Daily Stand-Up,, the team looks at it to let others know what they did the day before. Additionally, they recall or adjust priorities based on what they need to do for the next day(s).

🧐 During the Daily Stand-Up, developers also use the sprint backlog to evaluate the sprint's progress.

The sprint backlog is not only a way of keeping the development team's eyes on the prize. 👀 It's also a way to discuss how well they achieved the sprint goal.

At any point in a sprint, to-do, in-progress, and done items are included in the sprint backlog for anyone to review and use to calculate the remaining workload. This helps verify if the development team is on track to achieve the sprint goal. ✌️

Jira provides a burndown chart to check the development team's work. This displays the remaining workload for the current sprint. In addition, the chart shows:

• Work in progress
• The distribution of work throughout the iteration

A Jira burndown chart also helps evaluate whether additional items fit into the sprint and effort estimations were accurate.

🛑 Keep in mind that you don't need a sprint backlog if you follow the Kanban framework. That’s because Kanban isn’t about working in timeboxes (the sprints).

Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.

Besides defining what a sprint backlog is, we should discuss what sets them apart from product backlogs.

Sprint backlogs vs. product backlogs

Though their names are similar, a sprint backlog and product backlog serve different purposes. A product backlog is:

• A collection of work items to either bring a new product to the market or improve an existing product
• A list of work items to tackle in the future
• A set of work items arranged by priority, with the most priority at the top
• The source of the sprint backlog items

On the other hand, a sprint backlog is:

• A subset of work items from the product backlog
• A group of items to work on during the next sprint

Here’s how the two backlogs meet: The product backlog provides work items for a sprint backlog. And, by the end of a sprint, the team might transfer incomplete work to the next sprint or the product backlog. If the work items have high priority, they should go into the next sprint. If not, they should go into the product backlog for a later sprint.

Essentially, a product backlog covers a greater amount of time than a sprint backlog. However, like the sprint backlog, the product backlog might evolve to reflect changes in the market or customer needs and, the development team needs both in order to deliver product changes.

Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.

Who owns and creates sprint backlogs?

Here are the team members involved in creating sprint backlogs:

• The Scrum Master. During the Sprint Planning ceremony, the Scrum Master uses the product backlog to create the sprint backlog — the output. However, the Scrum Master doesn't do it alone.
• The development team. When moving product backlog items to the sprint backlog, the Scrum Master considers the development team's input. ⚖️
• The Product Owner. The Scrum Master needs the Product Owner's agreement to include product backlog items in the sprint backlog. 👌 And if the development team has questions about the product backlog, the Product Owner is the one to ask.

The sprint backlog's creation is one part of the agile workflow that shows how essential teamwork is to agile. Nevertheless, the sprint backlog must always be owned by someone throughout the workflow. Otherwise, these artifacts can get lost and become outdated.

Scrum methodology says that the whole agile team owns the Sprint Backlog. And by "agile team," we mean the Scrum Master, the Product Owner, and the development team.

That’s because all agile team members contribute:

• The Product Owner knows what the development team should deliver by the end of the sprint. Plus, they order product backlog items by priority. In other words, the Product Owner constrains the product backlog items that should go into the next sprint backlog.
• The Scrum Master has enough experience to distribute the development team's work throughout the sprint. When considering sprint backlog item dependencies, that distribution makes the most sense.
• The development team knows how long similar Sprint Backlog items take to complete. ⏲️ This means they can determine the sprint goal's feasibility within a certain time frame.

Remember, the sprint backlog is a living document, so team members should update it as needed. Let’s look at how a sprint backlog can change.

Updating the sprint backlog

The sprint backlog should adapt to answer market trends and customer needs as they arise. Those changes might influence items in the product backlog and how they’re prioritized. As a result, the sprint backlog changes.

Let's have a look at what may cause a sprint backlog to change and who makes the updates:

1. Effort estimations were not accurate enough. If the development team realizes that some work items will take longer than expected, they should raise a 🚩. They should then negotiate the scope of the sprint backlog with the Product Owner without compromising the sprint goal.
2. A new, higher-priority user story, task, or bug comes up. If that happens, the development team should add it to the sprint backlog. That might impact the sprint's duration or push some items to the next sprint.
3. Progress in completing a user story or a task or solving a bug changes daily. As this happens, the development team should keep updating the remaining workload they estimated for the current sprint. And they should do it during the Daily Stand-Up or Daily Scrum meeting. Once the development team finishes all the work in the sprint backlog, they achieve the sprint goal. This means the development team implemented the product increment, which is ready for delivery. 📦
4. A sprint backlog item is no longer needed. This might be due to a shift in the market or customer needs. If that happens, the development team should remove the item from the artifact. 🗑️
5. The development team better understands sprint backlog requirements as the sprint continues. So, they might realize that to achieve the sprint goal, they need to include more items in the sprint backlog.

The sprint backlog: A guide for sprint success

A sprint backlog is a guide for completing a sprint goal. This means that its lifecycle is short and equals the iteration's duration. It's a visual representation of the sprint that supports Scrum team discussions on in-progress and to-do work.

This backlog may also be the most reassuring Scrum artifact for developers, as it assures them the work is organized and no additional work items will fall from the sky without their knowledge. If the workload must increase, the team will debate it and weigh the developers' experience-based opinion.

With a sprint backlog, the team perfects its ability to plan sprints, estimate effort, and allocate resources. They learn how long work takes and how much of it fits into a sprint. And by learning this, the team learns the resources they need to get to the finish line.

Easy Agile TeamRhythm is collaborative sprint planning tool that helps your team with the shared context that the story map format provides. TeamRhythm helps your team to:

• Visualize a meaningful picture of work on the user story map, sequenced into sprint swimlanes
• Create, estimate and prioritize user stories right on the story map
• See comitment at a glance with sprint statistics and sprint goals displayed on each swimlane

Try planning your sprints with Easy Agile TeamRhythm. We’re confident it will help your team collaborate even more seamlessly.

“Do or do not; there is no try.” While this is certainly Jedi Master Yoda’s most famous quote, it doesn’t exactly apply to agile development. In fact, it’s kind of the opposite of agile. If Yoda were a Scrum Master, however, the quote would look a lot more like this: “Try and again try; that is how you do.”

The Scrum Master facilitates the Scrum team, leading them to a hopeful victory. It’s rewarding, but the Scrum Master role is filled with pressure. The success of the Scrum and the wellbeing of the team falls on the Scrum Master’s shoulders.

If you’re a Scrum Master or aspire to become one, you’ve come to the right place. Master Scrum theory and your leadership skills with our six strategies for Scrum Masters.

Understanding Scrum values and the role of the Scrum Master

Scrum is an agile practice commonly used for product development. It’s based on completing a set amount of work in short bursts — called sprints — so that teams can continuously create iterations as they learn more about a product and its stakeholders.

Ken Schwaber co-created the Scrum framework in the early 1990s to help teams manage complex development projects. He also founded Scrum Alliance and established Scrum.org, an online resource for agile teams.

At the beginning of a Scrum, the product owner decides which product backlog items will be moved to the sprint backlog. From there, the Scrum Master takes over, leading the team through Scrum events, including:

• Sprint planning
• Daily Scrum or daily standups
• Sprint review
• Sprint retrospectives

The role of the Scrum Master is to guide the team through the Scrum process. They facilitate the process, helping the team to master the framework and improve from one sprint to the next.

Characteristics that define a great Scrum Master

Being an effective Scrum Master goes beyond simply following the rules of Scrum. Here are some additional characteristics that truly define excellence in this role:

1. Emotional intelligence

A great Scrum Master possesses high emotional intelligence. This means they can:

• Understand and manage their own emotions.
• Empathize with the team members' feelings and perspectives.
• Facilitate constructive communication and resolve conflicts gracefully.

2. Strong facilitation skills

It's not just about managing the daily Scrum meetings. They need to:

• Encourage open dialogue.
• Ensure every voice is heard.
• Guide the team towards consensus without being overbearing.

3. Adaptability

The landscape of a project can change rapidly. Great Scrum Masters:

• Adapt to changes swiftly without losing focus.
• Help the team pivot strategies quickly while maintaining morale.

4. Lifelong learner

The world of Agile is always evolving. Exceptional Scrum Masters:

• Commit to continuous learning.
• Stay updated with the latest practices, tools, and methodologies.

5. Servant leadership

At the heart of a Scrum Master's role is servant leadership. This involves:

• Placing the team's needs above their own.
• Removing obstacles that hinder the team's progress.
• Empowering team members to take ownership and make decisions.

6. Analytical thinking

A great Scrum Master should be able to:

• Analyze the team's processes and identify bottlenecks.
• Use data-driven insights to foster continuous improvement.

7. Motivational skills

Keeping the team motivated is crucial for sustained productivity. They excel at:

• Recognizing and celebrating small wins.
• Encouraging a positive, collaborative team culture.

8. Excellent communication

Communication is key. They need to:

• Convey ideas clearly and concisely.
• Ensure that all stakeholders are on the same page.

By embodying these characteristics, a Scrum Master not only facilitates effective project management but also fosters a thriving team environment that encourages innovation and success.

Six strategies to become a great Scrum Master

Here are six strategies for Scrum Masters to improve their skills or prepare for their future roles.

1. Don’t forget to be agile yourself

Do you live by agile principles yourself? How agile are you in your leadership style?

Effective Scrum Masters know that they also need to continually improve based on new experiences, successes, and failures. It’s important to learn from your mistakes so that you don’t make them again, but it’s just as important to learn from your successes. Take the time to review your process, including what went well and what didn’t, so you know how you can improve as a leader and facilitator.

2. Get to know your team

Your ability to lead your team is tied to how well you know them. You should continually get to know your team’s strengths and weaknesses. How well do they work together? Who brings out the best in one another, and who doesn't work so well together? Dig deep to truly understand the root dynamics of the team.

Learn more about each individual on the team as well. What do they need help with? What do they excel at? What feedback can you provide to help them grow in their role? How can you help them succeed? Build rapport with your team members by asking how they’re doing, giving and receiving feedback, and finding common ground.

3. Foster a culture of continuous feedback

The agile methodology is based on continuous improvement. How will the individuals on your team improve if you don’t provide them feedback? Likewise, how will you improve if you don’t ask for, and accept, feedback from the team?

Feedback is a two-way street, and it only works if it’s constructive and continuous. Don’t wait until you have something negative to address — you need to regularly provide both positive and negative feedback. Doing this on a regular basis will help you and your team become accustomed to hearing feedback, so it won’t be jarring or off-putting when you do.

As the Scrum Master, you should foster an environment in which all members give and receive constructive feedback.

4. Hone your communication skills

Being in charge doesn’t mean you’re always doing the talking. The opposite is true: Great leaders are great communicators. As a leader, you need to constantly listen to your team, keeping both ears open for any issues your team or the individuals on it may be dealing with.

Actively listen to the concerns of the development team, and consider how each individual on your team prefers to communicate. Do they prefer bold and to-the-point interactions? Or do they need time to ease into a conversation? Everyone communicates a little differently, and understanding your team's preferences will help you make the most of each interaction.

Scrum Masters need to hone their communication skills in order to be effective leaders for their teams. Regularly assess your communication style and its effectiveness, and ask your team for feedback on how you are doing.

5. Make the most of every retrospective

The retrospective is the final event of a Scrum. They are an incredibly important part of the Scrum process, and they should not be overlooked, rushed, or underutilized. As the Scrum Master, you need to take responsibility for making sure retrospectives are effective and occur after each Scrum. Go in with a plan to make the most of every retro meeting.

That doesn’t mean you need to take charge of everything. It’s helpful to let your team run the occasional retrospective. Everyone involved should continually contribute their own ideas to improve the meeting.

Collect regular feedback from your team on how they think your retrospectives are going. Ask for ideas on how they could improve, and change things up. Repeating the exact same questions and retrospective activities will bore your team and lead to reduced engagement.

For more retrospective perspective, read our five steps to holding effective sprint retrospectives.

6. Become a certified Scrum Master

A Scrum Master certification can take you from simple Scrum Master to masterful Scrum Master. While certification isn’t required to become a professional Scrum Master, it certainly helps.

Scrum.org, the website founded by the co-creator of Scrum, offers a three-part certification program called The Professional Scrum MasterTM. The program has three assessment levels that validate your knowledge of the Scrum framework and practical application of Scrum theory.

• The Professional Scrum MasterTM I (PSM I)
• The Professional Scrum MasterTM II (PSM II)
• The Professional Scrum MasterTM III (PSM III)

We’re also big fans of Pretty Agile’s SAFe training programs:

• SAFe Scrum Master SSM Certification
• SAFe Advanced Scrum Master

A certification is a great addition to your resume, and it will help you fine-tune your facilitation skills and Scrum knowledge.

Easy Agile for Scrum Masters

“Try and again try; that is how you do.”

The beauty of agile is that regardless of how many certifications or years of experience you have, there’s always more to improve. Agile is an iterative process in which learning continues from sprint to sprint and project to project. As a Scrum Master, it’s up to you to continue learning the craft and perfecting your facilitation skills, the Scrum Master role involves life-long learning.

Easy Agile builds products designed to help Scrum Masters and agile developers work more efficiently and effectively. Our tools are specifically designed for teams that use and love Jira but need more functionality in order to prioritize customer needs.

Try Easy Agile TeamRhythm to support your team agility from planning through to review. TeamRhythm supports user story mapping, backlog refinement, sprint and version planning, and team retrospectives, building a continuous cycle of improvement right in Jira. It’s a win-win-win for Scrum Masters, development teams, and customers. Try our products absolutely free for 30 days.

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.

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:

1. 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.
2. 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. 😃
3. 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.
4. 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.
5. 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.
6. 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!

Kanban vs. Scrum — are they different, and can software and product development use them together? The answer to both questions is YES!

Both Kanban and Scrum are popular agile methodologies. They are different, but they can be used together. They are each part of agile, a better way of working that focuses on iteration and collaboration to reduce waste and maximize efficiency.

Agile is the antithesis of classical project management. Think of it like jazz vs classical music. Rather than one composer bringing an already composed and organized piece of music to an orchestra and dictating what happens where, jazz is collaborative, each band member feeds off of each other, creating music in an agile, iterative process.

This post will take a deep dive into both Kanban and Scrum methodologies. Continue reading to discover the differences and similarities between Kanban vs. Scrum, and learn how they can be effectively used together.

How is the agile methodology different from project management?

The traditional project management methodology is linear, meaning each project element is completed in sequential order. Only when each element is completed can you move onto the next one. Think of traditional project management as an assembly line. It has a strict succession of steps that are planned out by the project manager before any new work or iterations can begin.

The project manager is the person the entire team depends on for leadership. The flow of work remains the same from project to project, and the steps rarely evolve.

By contrast, agile is a non-linear way of working that focuses on flexibility and collaboration between team members. Agile project management focuses on getting something completed that stakeholders can see and evaluate on a regular basis, so value is continuously provided.

Each iteration yields new, actionable insights from both the team and the customer about what’s working, what isn’t, and what needs to change. It’s a multifaceted approach that eliminates the bottlenecks that can arise in the traditional method.

Kanban vs. Scrum

Kanban vs. Scrum is not a dichotomy. They are both agile methodologies designed to help teams work in an iterative process. They are both systems that are regularly used in the development process to ensure a value-driven approach. The goals and methodology are the same, but the steps are different.

A Kanban workflow is a way to visually organize tasks that ensures work items move forward while allowing changes and adjustments to be made along the way. A scrum works in 2-4 week sprints designed to complete a set amount of work or solve a specific problem. Throughout each sprint, teams check in daily to ensure progress and to identify any possible roadblocks.

Kanban vs. Scrum isn’t a one or the other choice. Both might be used at the same time, depending on what’s required of projects or user stories. Learn more about the differences and similarities of these two methods below.

Kanban vs. Scrum: Kanban methodology

Kanban was originally utilized by Taiichi Ohno, an engineer at Toyota, as a lean manufacturing system that decreased waste and increased efficiency. The Kanban method is a task management tool designed to maximize efficiency by visualizing all of the required work and limiting works in progress.

Work items are represented visually on Kanban boards so that every team member can see the state of each piece of work at any given time. It enables real-time communication and full transparency between team members since each work item is intentionally assigned. A Trello board is a simple example of a Kanban.

How to use Kanban

With a Kanban, work flows visually through various stages of completion to promote cohesive collaboration and real-time communication across teams. In its simplest form, a Kanban is a To-Do, Doing, and Done board. Work moves from one section to the next on a physical or digital Kanban board, depending on how far along the specific task is.

To solve more complex problems, which is usually the case in software development, a Kanban can become more advanced with added layers for specific clients, products, or deliverables.

A key aspect of the Kanban methodology is that each person is only allowed to work on one task at a time. This ensures no aspect ever moves too far forward without working in unison with the rest of the tasks on deck. The one-at-a-time system identifies critical connections between tasks as well as potential roadblocks that could cause delays.

Encouraging cross-functional teams to intentionally identify work items ensures tasks are appropriately prioritized. It also combats the negative effects of multitasking, allowing developers to zero in on one task at a time.

Kanban vs. Scrum: Scrum methodology

Scrum, sometimes called a “scrumban,” is based on empiricism and lean thinking. Empiricism is the belief that knowledge comes from hands-on experience and objective, observable facts. Lean thinking focuses on the essentials, bringing value to individuals while eliminating waste. A scrum uses real-time collaboration over theorization to provide a lightweight framework for solving complex problems.

The Scrum process uses an interactive and incremental approach that manages risk and enhances predictability through set intervals of iteration called sprints. The sprints yield an imperfect but valuable version of a product the team can quickly bring to stakeholders, whose feedback is then integrated into the next sprint. The sprints continue until the desired outcome or product is achieved.

How to use Scrum

A Scrum takes place over a set amount of time called a sprint. Each sprint generally takes two weeks to a maximum of four weeks to complete. The important part is that the time frame is set before the Scrum begins.

There are three main components of a Scrum:

1. Roles: The people

• Product owner
• Scrum master
• Development team

2. Artifacts: What gets done

• Product backlog
• Sprint backlog
• Increments

3. Ceremonies: Recurring events

• Sprint planning
• Daily Scrum
• Sprint review
• Sprint retrospective

The product owner orders and prioritizes backlog items, which are the aspects of a product that need completion. At the beginning of a Scrum, the product owner designates which artifacts from the product backlog move to the sprint backlog. The sprint backlog represents the goals and the desired outcomes of the upcoming sprint.

💡 Use Easy Agile TeamRhythm to transform flat product backlogs into impactful, visual representations.

The Scrum master helps everyone understand Scrum theory and practice. They are responsible for the effectiveness of the Scrum team. Throughout the 2-4 week sprint, the team focuses on the backlog, checking in for daily scrums or daily stand-ups. During these Scrum meetings, team members share what story points they completed, what story points they will complete next, as well as any roadblocks that stand in the way.

Deliverables are produced on a regular basis, and adjustments are made along the way as needed. A Scrum board or Kanban board might be used to help teams visualize their progress throughout the sprint.

Ceremonies are the recurring events held by Scrum teams cycling through on a 2-4 week basis. A Scrum begins with a short planning phase, then the work begins. The Scrum team meets daily to review progress and make changes as needed.

At the end of each sprint, a sprint review is held with stakeholders or clients to ensure value is being met, and continuous improvements are pushed forward. Lastly, a retrospective meeting takes place with the project owner, scrum master, and development team to review the past two weeks, including successes, key metrics, and challenges to be addressed before the next sprint begins.

Using Kanban and Scrum together

It doesn't need to be Kanban vs. Scrum — they can work together. A development team might choose to use the Kanban system within a Scrum to provide a visual representation of work moving forward throughout each sprint.

They are both valuable systems in your agile toolkit that work together to provide prioritization, collaboration, and constant value delivery. So, you don’t ever have to choose between Kanban vs. Scrum. Save the decision-making for the real problems, like what to put on the pizzas you order for your team. 🍕

A Scrum framework provides designated blocks of time for teams to complete a specific deliverable or set of deliverables while providing daily Scrum meetings to ensure cohesion and advancement. The Kanban system will ensure tasks are taken on one at a time in an evolving, visual process.

Learn the ways of the Scrum with Easy Agile

Easy Agile crafts solutions to make every agile team more effective. We help teams build simple and collaborative user story maps in Jira for backlog grooming, version planning, and silky-smooth sprints.

We believe there is a better way to work, and we want to help teams just like yours. Learn more about our suite of agile apps and follow our blog for the latest agile trends, tips, and more.

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.