“Every battle is won before it is fought.”
~ Sun Tzu
I’ve found that every small win or small difference, often makes the biggest difference in terms of impact. Imagine sprints as small battles, where your startup is fighting in an open arena. Every small victory accumulates, leading to the larger victory of the greater war – which involves outrunning your competition and owning the market.
Before every battle (or sprint), planning is key to achieve small wins and an overall greater victory.
In this article, we’ll teach you everything you need to know about Sprint planning and the steps to follow to run remote sprints. Here’s what we’ll cover:
2. Why is Sprint planning important?
4. How to run an effective Sprint planning meeting?
My goal is to give you the knowledge we gained through our experience practicing scrum (while building a Jira alternative for software teams- meta!), so you can apply it and gain weekly, bi-weekly and monthly progress.
What is Sprint Planning?
Sprint planning is one of the four Scrum ceremonies – Daily Scrum, Sprint Review, Sprint Planning, and Sprint Retrospective. The Sprint Planning meeting is the start of the sprint where product backlog items are reviewed, prioritized, and planned.
The sprint planning meeting is held at the beginning of every sprint. The goal of Sprint Planning is to prepare and align the team towards a common goal and delivering a pre-defined functionality. Based on the official Scrum Guide, the traditional duration is calculated based on the length of the sprint with the following recommended time limit:
Maximum planning duration (timebox) = 2 hours * N weeks in the Sprint
(e.g. 2-4 hours for 2-week sprints and 4-8 hours for 4-week sprints).
Keep in mind that the actual meeting duration varies greatly depending on a variety of factors, like the maturity of the team or how well-refined or organized the backlog items are. An effective sprint is not necessarily a longer one- if your team invests enough time in grooming the backlog, a one-week Sprint could be planned in 30 minutes to an hour using appropriate sprint planning tools to keep things organized.
At Tara, we usually allocate 30-45 minutes to plan our one-week Sprint. Best practice is to do this on Thursdays or Fridays. This enables us to avoid waste and, more importantly, secure the team’s focus. No meetings should ever run longer than needed- less is always more.
The sprint planning meeting has two main phases:
- Scope – What can be delivered in the sprint?
- Plan – How it’ll be delivered?
⚡ Spoiler alert: we live on our product, and all sprint planning and management at Tara, is completed on Tara.
Backlog
Backlog (or Product Backlog) is a breakdown of work to be done and contains an ordered-by-priority list of product requirements that need to be implemented by the development team. These backlog items can define features, bugs, and other product-related tasks.
Our backlog items are derived from tasks inside each requirement. Our users typically also import from other platforms such as Trello or Asana. We continuously refine and revisit the backlog, to make sure things don’t get out of hand in terms of length.
Scope
In the Scope phase, the team discusses the product backlog items and decides which ones can be included in the sprint. The Product Owner clarifies and answers the question that arises about the product backlog items. Note that the scope is always subject to changes- it can be re-negotiated as the team learns more throughout the development process.
💡Tip: The product backlog should be well-defined and ordered by priority before the Sprint planning meeting.
Plan
The team plans and estimates the backlog items which are included in the Sprint (a sprint planning template is handy at this stage if you’re a first timer). Backlog items that can’t be delivered within Sprint’s timeframe are split into smaller ones or removed from the sprint.
The team commits to the Sprint scope (goal) and the Scrum Master starts the Sprint. Everyone gets back to work.
Why is Sprint planning important?
Sprint planning is important (no second thoughts on that) but let’s talk through the benefits so you can convince yourself, convince your manager, or motivate your teammates to have regular and productive Sprint planning meetings.
Sprint Planning Benefits
- Development team members knowing their tasks
- Team communication and collaboration boost
- A common understanding of the product
- Solving complex problems as a team
- Aligning towards a common goal
- Team members committing to deliver results (before the deadline)
- Knowledge Transfer
- Surfaces different perspectives among teammates
Sprint Planning Roles (or Scrum Roles)
There are three roles in Sprint planning – Product Owner, Scrum Master, and the Development team. Each one of these roles has its purpose and responsibilities during Sprint planning.
Product Owner
The Product Owner represents the business and the users. They should be ready to clarify details of the backlog and be a resource for the team when questions about the backlog arise. The presentation of each backlog item should include why it was added in the first place (its purpose), the use cases it serves, its business rules, and all technical details required for estimation.
While setting priority for each backlog item, the product owner can re-prioritize it at any time as new feedback or feature requests roll in from users, but it’s best to keep changes to a minimum to ensure consistency and focus for engineers.
Scrum Master
The Scrum Master facilitates the organization of the Sprint planning meeting. Imagine them like the host of the party. They find a room, send calendar invitations, setup shared screens/projects, invite remote team members via video conferencing.
The Scrum Master’s core responsibility is to keep the order during the planning meeting and guide efficiently the team through the meeting’s agenda while keeping the team’s spirit high.
Development Team
The Development team usually consists of those who “develop” the product. While engineers are probably the first term that comes to your mind, this is not always the case. A dev tem can be made up of programmers, designers, or QA engineers who will work on delivering the items in the sprint backlog. Their goal is to ask questions about the backlog items, estimate and plan how the work will be delivered during the Sprint.
💡 Our quick take on Scrum roles: these roles are the definition of responsibilities rather than job titles. For example, in many companies, the lead engineer or the engineering manager can play the role of a Scrum master for the team, like us. In smaller startups, the founder can sometimes act as the product owner to help clarify what needs to be done and why. Remember, it is all about flexibility when it comes to adopting Scrum.
How to run an efficient Sprint Planning meeting?
Understanding Sprint planning, in theory, is one thing but running an efficient planning meeting in a real-world environment is a different thing. Even with the best sprint planning software, your first sprint planning meetings will be ineffective with wasted time (yes, we’ve been there). But don’t lose hope!
Sprint planning becomes more efficient with experienced agile teams and is designed to improve with each Sprint iteration. So take your time and persist! Also, we’ll provide you with key tips for creating a Sprint Planning meeting agenda– which have helped us eliminate mistakes and accelerated our productivity over the past few quarters.
Ready to learn the secrets?
0. Preparation
The Product Owner will first sync with internal or external stakeholders to define a list of product requirements to be developed in the next sprint. Then he/she and members of the development team, typically the lead engineer, create user stories, tasks, bugs, or other specifications and populate the backlog.
After the backlog is populated, the Product Owner orders the backlog by priority and business value based on inputs from business stakeholders.
1. Story Time (Pre-Planning Meeting)
For most teams that practice Scrum, the Product Owner and the Scrum master will meet to flesh out details of upcoming work before presenting to the team at sprint planning, or host a pre-planning meeting with the team to discuss the next sprints. At Tara, we call it “Story Time.” We typically host these meetings on Thursdays at 9:30 am, right before our stand-up.
This is the opportunity for everyone to sit down and review upcoming work so the dev team has a chance to think through and ask questions on the requirements, design specs, implementation plan, and work on breaking everything into development tasks. Items that are too big for one iteration or infeasible to deliver in the next Sprint are split into smaller chunks, modified, or if technically impossible removed.
If you are unsure of how to host an effective pre-planning meeting, take a quick look at the agenda for team Tara’s Story time:
Agenda for a 30-minute Story time at Tara
2. Estimation
The Development team discusses the product backlog items and estimates them in Story Points. The Scrum Master manages the estimation process to ensure that important details aren’t missed and that the team isn’t wasting time in unimportant discussions.
There are different estimation approaches but the most popular ones are Planning poker (all team members estimate all tasks), Selective Planning poker (only domain experts estimate tasks), and Developer Only (each developer estimates their tasks alone).
Story Points
A story point is abstract units that estimate the effort required to complete a task influenced by the amount of work, complexity, risks, and uncertainty. Story points have different work hours equivalent to the different team members because they depend on the developer’s velocity. At Tara, we call these story points “effort estimation”, which is equivalent to one work-day.
Velocity
Velocity is the amount of work a team (or a team member) can tackle during a single Sprint. It’s calculated at the end of each sprint as the sum of all user points on the fully-completed tasks.
Planning Poker
Planning poker (also known as Scrum Poker) is a process where multiple team members estimate a task without being biased by each other. It’s done by each team member secretly picking a card with a story points Fibonacci number (1, 3, 5, 8, 11, 21…) representing the estimation of the task.
Once all team members have picked a card, the cards are revealed. The final estimation is the average of all cards. If there’s a big difference between the min and the max estimation (e.g. 3 vs 21 story points), the estimation is called invalid.
When the estimation is invalid a discussion is started and the team members with the biggest estimation difference lay down their argument. The Planning poker process is repeated until a valid estimation is drawn. FYI- this might be overkill at the startup stage, but some teams can speak to the effectiveness of this strategy as it brings together multiple expert opinions.
💡Tip: For scrum poker tools, check out this iOS app, Android app or Play Scrummy, a web-based tool. A self-hosted version is also available on Github.
3. Sprint Scoping
The purpose of this process to decide which of the estimated and prioritized Backlog items can be realistically delivered in the upcoming Sprint. The Product owner starts to move items from the Backlog to the Sprint until the team is at full capacity. Sometimes the Scrum Master creates tasks on-the-go and assigns them to the responsible engineers.
The team’s full capacity is defined by the total of story points, or any indicator of effort estimation, in the Sprint reaching the team’s velocity. The Scrum Master is responsible for monitoring the points assigned to each team member to ensure that they aren’t overwhelmed with tasks or left without work to do.
💡 Best Practice: Many teams choose to add buffers based on changes that typically happen in a sprint. Buffers are added to tackle unforeseen items such as incoming bugs during a sprint.
4. Sprint Planning
Now that everyone has a clear vision and knows exactly what they will be working on during the next Sprint, the Development team can put the sprint plan in place and commit to delivering the items that have been added.
Remember to always conduct the feasibility check. In a perfect world, this wouldn’t be necessary but the feasibility check’s purpose is to verify that the Sprint scope can be delivered considering all possible blockers and conditions.
Simply put; there are several conditions where a team cannot work at full capacity during a sprint, namely:
- Official holidays & vacations
- Team member’s days off
- 3rd party contractors dependency
- Platform limitations (e.g. waiting for approval on Google Play/App Store)
- An employee getting sick (especially, in the flu season)
- Critical bugs from previous sprints
5. Commitment and start of the Sprint!
The final step of the Sprint planning meeting is to start the sprint. But before doing so, each team member should go through their tasks again and commit to delivering them during the Sprint.
The Scrum Master, like a caring and empathic leader, will make sure that each team member is comfortable with their commitment. When everyone is ready, the Scrum Master will start the Sprint. Let’s go sprinters!
💡Tip: The Scrum Master should be extra careful when choosing the start and end dates of the Sprint especially in the holiday season (again, feasibility check). This is important because they might give less working days to the team and create tension when the commitments aren’t met.
Final Words
To recap, Sprint Planning (aka the Sprint planning meeting) is one of the four Scrum ceremonies. It’s held at the beginning of every sprint and its goal is to align the team to deliver a common goal by the end of the Sprint.
Keep in mind that any framework is meant to provide guidance and a starting point. These rituals are not set in stone and should be adapted based on each team’s goals and needs. Remember, there is no one-size-fits-all model for teams to apply.
For Teams New To Sprints
Scrum centers around organization, flexibility, and continuous improvement. Not everything will go exactly as planned, and the majority of the time you may find yourself in a constant state of experimenting and refining. That’s part of the team building process- as teams learn to communicate and understand each other, there’s more clarity around the what, why, and hows that are crucial to building a solid plan.
So, how do you plan the optimal sprint? Our goal as a platform is to build smart capabilities in project management. One way we help with sprint planning is through a sprint load indicator. The indicator develops an understanding of your most recent team capacity, based on effort completed in ongoing sprints. As you plan your team’s sprint, the indicator notifies you if you are overloading your sprint. The idea is to help teams reach completion state more frequently with the indicator, as it develops a better understanding of the team’s capacity. There’s more to come for indicators on Tara and we’re excited to see how smart predictions (such as this one) could deliver real value to teams.
Our “overload indicator” on the sprint column
Next steps…
Over the last few months, we’ve also added internal teams that sit outside of engineering (i.e. growth) into our sprint methodology and we’re learning that sprints are versatile enough to be used in marketing and growth. Currently, we run simultaneous sprints across all teams at Tara, and we’re finding that in a remote environment, they help instill priority and focus.
We’ve discovered that as a result of effective sprints, we’re now on a weekly cadence of releases in our product. As an added bonus, we had very little difficulty moving to a remote organization, as our on-going sprints already provided the time-based structure, prioritization and discipline to continue shipping product with limited disruption.
I’m curious to hear how you’ve used sprints effectively in your teams, to enable productivity in a remote environment. Leave your comments below or shoot us a tweet @taradotai.
💡If you want to take your Sprint Planning and team’s productivity to a whole new level, check out Tara – the smart and free alternative to Jira. We’re working hard to build modern sprint management software, to prevent sprint planning mistakes and increase velocity. Stay tuned!