Post 4: Becoming Agile
Agile Meetings: Sprint Planning
Introduction
I hope you are enjoying reading the Becoming Agile series.
Part of the Becoming Agile process is maturing the use of Agile meetings to support the building of a high performing, self organising team.
The current series of posts are looking into what you should consider as the four essential Agile meetings/ceremonies:
Daily Standups;
Sprint Planning;
Sprint Retrospectives, and;
Sprint Review/Showcase.
There is a separate post focused on one of these meetings. The structure of each post will focus on the goals for each ceremony, best practices, potential pitfalls, and tips to ensure your teams can get the most value from them.
This post will focus on Sprint Planning.
Why work in Sprints?
A “Sprint” is a fixed period of time, sometimes called a “time-box” or “iteration”, during which a team works to complete a set amount of work from the Product Backlog.
Working in short time-boxes, or “Sprints”, aims to improve productivity by providing structured focus for your team’s work. Similar to how an individual might use the Pomodoro Technique (Cirillo, 2018) to improve their personal productivity, your team does it in Sprints. The idea of a Sprint is that by working within set intervals, teams and individuals create a rhythm that aims to enhance concentration and reduce procrastination (Bailey & Konstan, 2006). Research on cognitive workload management suggests that time constraints, like those provided by Sprints, will improve efficiency by limiting cognitive overload and decision fatigue (Newport, 2016).
In IT projects, where deliverables often compete for attention, and resources can get side-tracked doing lower priority work - time-boxing forces prioritisation and structured decision-making. Becoming Agile and implementing Sprints aims to leverage productivity principles by ensuring teams set realistic goals, break work into manageable increments, and reflect on outcomes in iterative cycles (Schwaber & Sutherland, 2020). This cycle of delivering, reviewing, and adjusting fosters continuous improvement and transparency, making time-boxing a crucial productivity strategy in IT project management.
How Sprints Help Manage the “Triangle”
The three key constraints in traditional project management are Time, Scope, and Cost - often referred to as the “Project Management Triangle”.
Time - the schedule and deadlines for project completion. This includes planning, development, and delivery timelines.
Scope - all the work required to achieve the project's objectives, including deliverables, features, and functionalities.
Cost - the budget and resources allocated to the project, including labor, materials, and operational expenses.
These three constraints are the interconnected imposed limits that apply to all projects. Project management teaches that changes to one of these constraints will affect the others. It is taught that if the scope increases, it will either take more time to complete, or the costs will rise (e.g., hiring more resources). If the time is reduced, either costs increase (e.g., overtime, additional staff) or scope must be reduced to stick to the deadline.
Sprint Planning aims to help simplify the application of this project management theory by fixing the time period, the scope, and the resources within a Sprint. It helps people to have meaningful conversations about what work is in scope in the next two weeks. It allows for iterative progress towards project goals, and allows for regular assessment of work completed. This structured approach enables teams to track tasks more effectively, aligning progress with project milestones. It reduces the risk that resources will spend long periods of time on work without checking their work is aligned, delivering appropriate value and confirming that the project as a whole remains on track.
Working in Sprints also helps to make sure that risks to deliverables are being actively managed. Unlike open-ended tasks or deliverable based management, which can lead to inefficiencies and a lack of accountability, time-boxing enforces team discipline around all three of the key constraints for all projects. In IT projects, where multiple tasks, deliverables and dependencies exist, time-boxing ensures that work is systematically planned, reducing the likelihood of scope creep and delays (Schwaber & Sutherland, 2020).
Characteristics of a Sprint
1. Fixed Duration - a Sprint typically lasts between one to four weeks, with two weeks being the most common.
2. Consistent Cadence - Sprints occur one after another without gaps.
3. Focused on Deliverables - you work in Sprints because they allow the team to focus on completing agreed goals and tasks within that timebox.
4. Maintaining Sprint Focus - once a Sprint begins, the scope is fixed, to provide stability and focus. However, the team should anticipate potential blockers, and some contingency tasks if work is delivered early as part of Sprint Planning. These tasks, and any mid-Sprint adjustments should be made collaboratively to ensure they align with the Sprint Goal.
5. Ends with a Review - each Sprint concludes with a Sprint Review or Showcase (to celebrate the value of the increment delivered) and a Sprint Retrospective (to improve the process).
A Sprint aims to contribute to the continuous delivery of value in small, manageable iterations.
The Sprint Planning session is a fundamental Agile meeting where the team works to collaboratively define the work to be delivered in the upcoming sprint. It ensures each team member has sufficient work on, that the team is aligned in the direction, has clear goals, and a structured plan for execution of the Sprint.
Sprint Planning
Purpose and Goals
Sprint Planning is a meeting that happens at the beginning of each sprint where the team defines the goals for the sprint and the work to be completed in the Sprint.
The primary goals of Sprint Planning are:
Aligning the team on the purpose for the Sprint (Time).
Defining and prioritising backlog items to be completed (Scope).
Estimating effort and capacity for the sprint (Cost).
A well-structured Sprint Planning session fosters transparency, accountability, and a shared commitment to delivering value within the sprint (Schwaber & Sutherland, 2020).
Format
Sprint Planning typically consists of two parts:
What can be delivered in this sprint? – The team looks at the backlog, prioritises backlog items, and discusses what can be achieved within the sprint’s timeframe.
How will the work be completed? – The team breaks down backlog items into actionable tasks and estimates the effort required.
Collaborative Sprint Planning
Sprint Planning is a team effort. It’s not just the manager’s job to prepare and decide everything, everyone plays a role in making sure we have a clear and achievable sprint plan.
Here’s how teams work together at each stage:
Before Sprint Planning: Getting Ready
Writing and Refining Backlog Items - anyone on the team can create and update backlog items. If work is identified that needs to be done, it is captured in the backlog with enough definition and detail for the team to understand and discuss it.
Discussing Priorities - team members can speak up about what they think is important, and what work needs to be done in what order and what risks and dependencies exist. Product Owners and managers can obviously influence, guide and direct priorities, as required, but team members with knowledge and expertise can define, direct and advocate for work they see as necessary and valuable.
Understanding the Work - reading the backlog, adding to it, asking questions, defining and refining items in the backlog before Sprint Planning has to happen for the session to be effective and efficient. Team members are active contributors, they are not showing up to Sprint Planning to “learn” what the Sprint is about.
During Sprint Planning: Aligning and Committing
Agreeing on the Sprint Goal - the team, managers, Scrum Masters and Product Owner discuss what needs to be achieved in the Sprint.
Selecting and Refining Work - the team picks the backlog items that align and support the goal, prioritising based on business value and capacity.
Estimating Effort - the team estimates the effort required to ensure the workload is realistic.
Finalising Tasks - if backlog items aren’t well-defined, the team can help refine them together before committing them to the Sprint Plan.
After Sprint Planning: Executing and Improving
Delivering the Work - team members take ownership of tasks and collaborate throughout the sprint to make sure the work gets done.
Adjusting as Needed - if someone needs help, or something needs to change in how work gets done, the team discusses it and adapts, rather than waiting until the end of the Sprint to raise it. If work gets blocked (can’t progress), work can be done to unblock it, and if required, team members can support completion of other prioritised work in the Sprint Plan if necessary.
Improving the Backlog - team members can keep refining backlog items and adding tasks during a Sprint. Sprint Planning isn’t the only time to document work, you do not want team members trying to remember things until the next Sprint Planning session, you want them to quickly document it in the Backlog, it is an ongoing process.
Example Sprint Planning Discussion
Sprint Planning Facilitator: Morning team! Welcome to Sprint Planning.
In this Sprint, we will be focused on delivering high-priority features while ensuring we break down tasks effectively and consider dependencies. Our key activities today are:
Reviewing the top backlog items and confirming priorities.
Breaking down user stories into tasks and estimating effort.
Identifying dependencies, risks, and any gaps in our plan.
Committing to what we believe is achievable within the Sprint.
Product Owner: Our Sprint Goal this time is to enhance user authentication and ensure smoother onboarding. We aim to deliver the core authentication features while ensuring we maintain high security and usability standards. Let's align on what we can realistically achieve within this Sprint.
Sprint Planning Facilitator: I was trying to write the goal as a user story to keep us focused on the end user as our customer. Here is what I came up with:
“As a new or returning user, I want to log in, reset my password, and securely authenticate using multi-factor authentication (MFA) so that I can access my account safely and seamlessly, ensuring a smooth onboarding and login experience."
I know it is not perfect, so I’ll leave it on the board, tag anything you think we could add or change, and we can loop back to locking this in later in the session.
We've got a lot of work to get done—how do we want to approach it in this Sprint?
Developer: You know what they say about how to eat an elephant? You do it one bite at a time!
Tester: You’re very wise. In that case, my elephant steak in this Sprint will be writing the test scripts for the new features and conducting more user testing for the home screens.
Other Developer: I think we need to prioritize the user authentication feature for this Sprint. Based on the Sprint Goal and backlog priorities, this includes login, password reset, and multi-factor authentication (MFA) work.
Developer: The login and password reset features should be straightforward. MFA is huge, so we might need to break that down, and we need to include our security team in those discussions since they’re a key dependency for us.
Sprint Planning Facilitator: This sounds good. Let's go into breakout rooms to refine the feature work, break down the backlog tasks, and review the acceptance criteria. Aim to estimate the effort involved, and we’ll regroup in 20 minutes.
— (After breakout session) —
Sprint Planning Facilitator: Welcome back! Based on your discussions, let’s align on what we’ve agreed to commit to this Sprint.
Developer: For user authentication, we’re tackling login and password reset in full. MFA will be broken into initial setup and integration tasks, but we need security input before committing to the full implementation.
Tester: I’ll be focusing on test scripts for login and password reset, as well as early exploratory testing for the new home screens.
Other Developer: We also identified a need to refactor some authentication-related API calls, which we’ll handle in parallel.
Product Owner: Great! This aligns with our Sprint Goal. Let’s lock in our commitments and move forward with confidence.
Sprint Planning: Starting with Confidence
Sprint Planning might feel a bit daunting at first. The aim of “Becoming Agile” is to learn by doing, trust the process, refine as you go and improve your practice over time. The key is to start, embrace the learning opportunity, and empower your team to learn and support you as you do it. Every Sprint Planning session will benefit from what you will learn in the Sprint Reviews and Sprint Retrospectives, so give yourself permission to try things, reflect, experiment and improve in every Sprint.
Tips for Better Sprint Planning
Set a Clear Sprint Goal
A well-defined Sprint Goal is sometimes referred to as a “North Star” - because it helps set the direction and keeps the team focused on where you are going and what really matters. It ensures that even if unexpected challenges come up, the team can adjust and make decisions based on the priority and be confident they are still working toward the right outcome.
Not sure how to phrase your Sprint Goal? You can try using a user story format:
"As a [user], I want to [achieve this], so that [benefit happens]."
For example:
"As a returning user, I want a smooth login and password reset experience, so that I can securely access my account without frustration."
Doing this keeps the project focused on the people who will use what you build. If discussions start drifting during the Sprint, or get too bogged down in technical complexity, remembering that the use and value of what you’re doing can help cut through to what is important. Checking back on the Sprint Goal as the Sprint progresses will help the team stay on track.
Limit Work in Progress (WIP)
A common mistake is trying to do too much into a Sprint. It might seem counter-intuitive at first, but your goal is to achieve results, build momentum and achieve stability and confidence in your team. The goal is discipline in approach and focus, not overshooting and introducing chaos and complexity by going for volume. If you find yourselves stretching too thin, prioritise ruthlessly - commit to what delivers the most value right now. Ask the team in the Sprint Planning session what is important and what can wait, encourage the discussion - it will help get buy-in. Trust that anything not tackled this Sprint will get done in time, and will rise to the top of the backlog when the time is right.
Ensure Team Participation
The Sprint Planning process isn’t just for the Scrum Master or Product Owner - it’s for everyone. Developers, testers, designers—each person brings valuable insight. Encourage people to speak up, ask questions, and challenge assumptions. A well-planned Sprint means fewer surprises later. And if things don’t go perfectly - that is what Daily Standups and Retrospectives are for. Agile is about adapting, not predicting everything perfectly.
Tools for Better Sprint Planning
Try Using Different Estimation Techniques
Estimating work isn’t about being exact, it’s about gaining shared understanding. If your team is new to estimation, start simple:
T-shirt Sizing – think of tasks as Small, Medium, or Large instead of exact hours. This is my favourite, I think everyone can understand this language and the difference between a Small and an Extra Large.
Fibonacci Sizing – Using the numbers like 1, 2, 3, 5, 8, 13 to represent effort. The bigger the number, the harder it is to estimate precisely - if something is a 13 or more, it’s probably too big and needs to be broken down. These numbers also aim to limit arguing about if something is a 3 or a 4, or an 8 or a 9 - and getting agreement on the size of tasks.
It will likely feel a bit artificial at first, but your team will get better at this with experience. The goal isn’t perfection, but alignment and confidence in what you’re committing to do in the Sprint.
Common Pitfalls and How to Overcome Them
Overcommitting
Why it happens: Teams want to be ambitious, but end up taking on more than they can finish.
How to avoid it: be realistic about capacity - consider meetings, potential risks related to unplanned work, and task dependencies.
Ask the team: can we comfortably complete this in a Sprint?
Vague Sprint Goals
Why it happens: The team doesn’t have a clear outcome in mind, leading to scattered work.
How to avoid it: Keep the goal specific and user-focused.
Ask the team: “What problem are we solving this Sprint?”
Ignoring Capacity Constraints
Why it happens: Teams forget about leave, dependencies, or bottlenecks.
How to avoid it: factor in team availability - and plan for interruptions. Allow time for teams to learn. If a key person is away, adjust expectations early. Encourage the team to think about who is available, what might slow them down, and what external factors (like leave or dependencies) could impact delivery - this can help the team to adjust expectations in the planning session, not be trying to react during the Sprint when you want them focused on their tasks.
Ask the team: "Do we have the right people available to complete this work, and are there any potential blockers or dependencies we need to plan for?"
Conclusion
Trust the Process and Your Team
Every Sprint Planning session is a chance to learn and improve. Some will go smoothly, others might feel messy—and that’s okay. Trust that your Daily Standups, Sprint Reviews, and Retrospectives will help you fine-tune along the way. If something doesn’t go to plan - you can adapt. If you’re not sure - you can ask the team.
The reason this series is about Becoming Agile is that you’re always evolving, and always aiming to get better. Be clear with the team that you’re all learning, you are planning the next chunk work for the next chunk of time. When it comes to Sprint Planning, remember - the ultimate goal is that each one will be better than the last one. Trust that everyone in your team will be helping and working together to make sure they are.
References
Agile Alliance. (n.d.). Sprint Planning. Agile Alliance. https://www.agilealliance.org/glossary/sprint-planning
Bailey, B. P., & Konstan, J. A. (2006). On the need for attention-aware systems: Measuring effects of interruption on task performance, error rate, and affective state. Computers in Human Behavior, 22(4), 685–708. https://doi.org/10.1016/j.chb.2005.12.009
Cirillo, F. (2018). The Pomodoro technique: The acclaimed time-management system that has transformed how we work. Currency.
Cobb, C.G. (2023). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach (2nd ed.). Wiley.
Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.
Cohn, M. (n.d.). Agile planning. Mountain Goat Software. Retrieved March 12, 2025, from https://www.mountaingoatsoftware.com/agile/agile-planning
Highsmith, J. (2004). Agile Project Management: Creating Innovative Products. Addison-Wesley. Jim Highsmith discusses Agile project management practices, with a focus on planning iterations and sprints.
Newport, C. (2016). Deep work: Rules for focused success in a distracted world. Grand Central Publishing.
Productivity Guy. (2020, June 15). What is Pomodoro technique | Explained in 2 min [Video]. YouTube.
Sutherland, J., & Sutherland, J.J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business. https://www.agileleanhouse.com/lib/lib/News/More_Praise_for_Scrum_The_Art_of_Doing_T.pdf
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org.https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf