Sprint plans – what they are and when to implement them

How do you hit a moving target?

Countless companies have thrown a lot of money and resources into answering that question.

Targets move for a variety of reasons, ranging from new competitive forces entering the market, to consumer demand changes, and even technology disruption. The world is rapidly evolving and becoming even more connected.

Things are moving so fast that even the books that once had the answers can feel out-of-date before they hit the shelves. It’s not enough to put out a good product anymore — you have to work hard to keep it that way.

The secret sauce to ensuring you consistently come out on top might lie in sprint planning.

Sprint plans keep your company agile and ready to shift priorities at a moment’s notice. According to new research, 79% of companies following Agile practices use sprint planning as their go-to method for getting work done efficiently and effectively.

In this article, we’ll provide a comprehensive look at what a sprint plan is, how to implement one, and what software can give you a leg up.

What are sprint plans?

If you’re new to working in an Agile environment or need a refresher on sprint planning, then it’s good to start with some simple definitions and benefits.

Let’s start at the top.

Sprints are ways to organize and deliver work, often used within the Scrum project management framework. Each sprint is a 1–4-week period where your team pushes everything aside to focus on a narrow list of tasks that’ll help achieve a desired outcome.

What, what’s Scrum?

Scrum is one of numerous frameworks that sit under the Agile project management methodology. If you’re unfamiliar with it, check out this in-depth article.

Sprint planning is 1 of 4 key meetings — or ceremonies — that happen during each sprint. And it’s where you — wait for it — plan the sprint. Kind of self-explanatory, that one.

The sprint plan is the outcome of the sprint planning meeting.

To put it plainly, a sprint plan narrows down the infinite work combinations and ideas you could pursue in a short 1–4 week period, and helps you arrive at a tight cluster of tasks that have the highest priority and value to the customer and the company.

But we’re not quite done with the definitions yet, so bear with us.

When working as part of a Scrum team, you’ll often hear the word artifact, which is a fancy term that simply represents value or work.

Ultimately, there are 2 important artifacts that result from a successful sprint planning meeting: the sprint goal and the sprint backlog.

A sprint goal is a sentence or 2 that describes what the team hopes to accomplish during the sprint.

Often, it’s written in collaboration between all members of the team, including the product owner who represents the interests of the business.

The sprint goal makes it easy to explain to stakeholders what the current priorities are and simultaneously acts as a North star during the sprint to keep everyone on track.

A sprint backlog is the specific set of tasks the team’s looking to complete during the sprint.

Where does it come from?

Well, Scrum teams maintain a product backlog, which is essentially an overall list of everything that needs to happen for the project to be a success. Product backlog items come from a wide variety of sources, including customer feature requests, bugs, and internal feedback.

When it’s time to plan a sprint, the team will review and prioritize the product backlog and move over to the sprint backlog all the items they plan to complete during the sprint.

Try monday dev

Selecting the optimal length for your sprint

Sprint performance depends on a wide variety of factors, including the length of the sprint. While there’s no one-size-fits-all approach to timing your sprints, there are some best practices that’ll help you decide.

Let’s examine each sprint timeline starting with shorter sprints:

• 1-week sprints: ideal for teams that thrive in fast-paced environments and can consistently produce new features, bug fixes, and product updates each week.

• 2-week sprints: largely considered the “sweet spot,” 2-week sprints are efficient at increasing velocity and productivity without sacrificing quality.

• 3-week sprints: a go-to cadence for teams who aren’t used to fast-paced work or who are new to Agile.

• 4-week sprints: the maximum acceptable length of time for a sprint, rarely used except for large, complex, lengthy Agile projects or hybrids (where companies are trying to embrace Agile without entirely giving up the old ways.)

If your “sprints” are longer than 4 weeks, then they simply aren’t sprints anymore. That’s just regular old work.

If you’re unsure where to start, it’s best to conduct an experiment. Start with shorter sprints like 2-week sprints and see if the team adapts over a 4-6 week period.

If they’re crushing it, then give 1-week a try. If they’re struggling, then dial it back to a 3-week cadence.

When to implement a Scrum sprint plan

Scrum’s framework isn’t ideal for all work, but it can have a transformative effect when used correctly.

There are unlimited options to structure your work, and — before going too far down the rabbit hole — it’s good to take a step back and reflect on whether Scrum is really right for you.

Ideally, your team is full of self-starters who require little to no oversight. Teams who thrive using Scrum and sprint planning include those where:

• Project requirements aren’t clearly defined
• Product testing before launch is beneficial
• The probability of change is high
• The culture is innovation-focused

Scrum is especially popular in the IT and software development industries, but it’s also making its mark in other industries such as financial services, construction, engineering, and manufacturing. The list goes on and on.

(Image Source)

The sky’s the limit to the potential for Scrum sprint planning, and now that you know it’s a good fit for your team, it’s time to dig into the actual day-to-day of working in sprints.

Sprint planning meeting preparation

Every Scrum team begins their sprint plans with a sprint planning meeting.

A general rule of thumb is to multiply the sprint duration by 2 hours to figure out how many hours it will take to cover all the necessary topics. For example, if you’re doing 2-week sprints, you’d multiply that by 2 to get a 4-hour meeting.

Now that the duration is settled, it’s time to see how each Scrum role prepares for the meeting:

Scrum Master (if applicable)

• Schedules the meeting and ensures all the right people are invited
• Prepares and publishes an agenda for the meeting
• Ensures each team member’s skills align with the needs of backlog items for the upcoming sprint

Product Owner

• Ensures all user stories and features are bite-sized enough to complete within the upcoming sprint timeline
• Provides all backlog items with acceptance criteria (AKA test scenarios) and detailed requirements
• Prioritizes backlog items to ensure the most important items are at the top and meet the team’s definition of ready

Development Team

• Defines work and effort, so everyone fully understands what’s expected of them
• Consistently looks back at the previous sprint to ensure lessons learned are carried over
• Ensures the Definition of Done is up to date, meaning that everyone agrees as to what list of requirements exist to qualify all work as being complete or shippable

(Image Source)

It’s a good idea to bring the product roadmap to the meeting alongside the product backlog to ensure the development team understands the big-picture view and ultimate vision for the product.

The product roadmap is a high-level view of the major elements of the project, and it might look something like this:

Running a Scrum sprint planning meeting

Now that you have the details sorted out and everyone knows their role, it’s time to run a sprint planning session.

While it may seem like a lot of moving pieces, it’s actually a simple process that empowers everyone to do their best work.

Here we break it down into 6 concise steps:

1. Settle on the sprint goal

It’s always good to start with the end in mind. Knowing the outcome, you hope to achieve upfront makes it infinitely easier to determine which backlog items become a part of the sprint.

When setting the sprint goal, it’s also important to use the SMART framework. Here are questions you can ask to ensure you’re on the right track:

• Is the goal specific?
• Is the goal measurable?
• Is the goal achievable?
• Is the goal relevant?
• Is the goal time-bound?

Ideally, all goals should be specific enough to know when you’ve finished. This is not the time for ambiguity or vague goals.

If there’s a clear metric or ability to measure the goal, then you’re likely on the right track. You also want to ensure your goal is realistic and that you’re not straining resources to achieve it.

Relevance is important to any Agile sprint because although 2-week sprints aren’t a long time, you also don’t want to waste it by working on something that isn’t valuable. Finally, time-bound fits nicely based on your sprint timeline.

Following the SMART framework is the best possible sprint planning template because it ensures everyone understands the goal, knows their part, and isn’t confused.

2. Shift items from the product backlog to the sprint backlog

With everyone on the same page, you can decide on what items fulfill the sprint goal. A good place to start is with the lowest hanging fruit. If there are some easy wins that’ll help build momentum, those should end up near the top.

If you’re using software like monday.com, it’s as easy as selecting the backlog item and moving it to the correct sprint.

As you move through the product backlog items, make sure everything you’re dragging over matches the team’s skillset, goal, and current capacity. Here are some good questions to ask:

• Which backlog items contribute the most to our overall sprint goal?
• Which backlog items provide the greatest customer value?
• Which backlog items are riskiest or most expensive?
• Which backlog items have a thorough user story?
• Which backlog items have dependencies?
• Which backlog items are easiest?

If something needs a specialist or falls outside of scope, then it may be best to save that for another sprint.

3. Let the team divvy up work amongst themselves

If the team is fully staffed and has the right balance of experience, then this should be the easy part. Unlike most work structures, Scrum is all about self-management.

You’ll hear team members say “I’ll take x,y, and z” more than a Scrum master or manager telling people what to do.

With Scrum sprint planning, the team knows their expertise best and will help decide who owns what, but that doesn’t mean there aren’t things to still consider.

For instance, holidays and planned time off can really derail a sprint’s success, so it’s important to call those out upfront.

Same goes for limited bandwidth. If your development team is cross-functional and has their hands in other sprints or other areas of the business, it’s good to call that out upfront.

Once the plan is ironed out and everyone knows who’s owning what, you can assign tasks in your project management software.

4. Create crystal clear dependencies

Now that you’ve determined what tasks will help achieve your goal and who’ll own them, it’s time to put them in order. Task order is vital to any successful sprint and isn’t something you should overlook.

If there are task dependencies within your sprint, then now’s the time to determine what sequence they’ll need completing in order to move forward.

Now, don’t go creating dependencies where there aren’t any because that’ll slow down the project’s progress.

But be clear about those that exist and find ways to be creative so that the team can get as much work done as possible without actively waiting on another task’s completion.

Now that your plan for sprint success is ironed out, it’s time to find ways to ensure everything’s on track to completion.

5. Take velocity into account

It’s not enough to set a plan in motion. Sometimes you have to shift priorities or provide a little extra motivation. That’s where velocity comes into play.

Velocity is the measurement of time that originates from the number of tasks, story points, and hours worked.

When measuring in story points, it’s worth noting that they aren’t an exact measurement of time. Instead, they’re based on relative difficulty. At monday.com, we equate 1 story point to roughly 1 day of work.

You calculate velocity by taking the average number of completed story points over the last several sprints and remove any incomplete stories.

If your team completed 50 story points over 5 sprints, then your velocity is 10. With that average velocity, it’s safe to assume that you can achieve 10 story points in the next sprint.

If you track velocity over time, then you’ll find patterns and trends that help you make better decisions.

6. Get your hands dirty

Now that everyone knows what to do and when to do it, it’s time to get to work.

Teams who work in sprints do so with very little oversight and are good about checking in with each other to see where they can assist colleagues.

Stick to the plan, and good things happen in the end. And don’t forget to make time to learn from the previous sprint, so each one is at least 1% better than the last.

How sprint planning can go wrong

There are unlimited scenarios in which your sprint plan can go awry, from technical issues to unplanned bug fixes and unrealistic timelines—some things you simply can’t prevent.

The best you can do is mitigate their effects when they do pop up. To do that, it’s best to put systems in place that leave wiggle room for the unexpected.

One way to leave wiggle room is by not overextending the team.

The absolute worst thing you can do when sprint planning is take on a goal that’s too ambitious for the timeframe or resources at your disposal.

The best way to avoid such a scenario is to encourage your team to speak up when things aren’t clear and to ensure there’s plenty of downtime in case conflicting priorities crop up.

Essentially, what you’re trying to do is avoid the planning fallacy, which is a phenomenon that occurs when people have an optimism bias and underestimate how much time is needed to complete a future task.

With an Agile sprint, it’s good to adjust the scope of the sprint to avoid repeating the planning fallacy.

At monday.com, we like to plan 4 story points — which are roughly 1 day of work each — for a 1-week sprint. This leaves us 1 extra day of wiggle room for dealing with unexpected bugs, issues, and other delays.

Manage a successful Scrum sprint plan with monday.com

Sprint planning with monday.com means fewer headaches and greater automation. So, you can do more of what’s important and less admin work with our sprint planning boards.

For starters, you’re going to need a Feature Backlog Template like the one below:

The product backlog acts as your wish list of sorts and is likely full of feature ideas from all areas of the business, including stakeholders.

When you’re conducting a sprint, you’ll pull priority items from the feature backlog to your sprint backlog.

Next up, you may need a Bug Tracking Template to keep up with what *cough* bugs you.

The bug tracking board will show you the source, status, customer impact, key dates, and where it fits into your upcoming plan.

Finally, you’ll want to conduct your sprint planning session and fill up your Sprint Planning Board.

All sprints will follow a similar structure with static columns like assignee, status, priority, estimation, status, and epic. That way, everyone knows exactly who’s working on what and the current status.

Beyond tracking your sprint, monday.com makes it easy to communicate with your team via tagging, notifications, and integrations to popular chat and video conferencing software.

Creating your own sprint plans

monday.com combined with sprint plans is a double threat. It makes what’s typically a volatile process full of surprises more predictable. In essence, it puts that moving target in slow motion, so you’re more likely to hit it consistently.

If you’re making a plan for your next sprint, then our Sprint Planning Template is an invaluable resource. It has everything you need, and nothing you don’t, so your team can focus on what’s important.

What are you waiting for?

Try monday dev