Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Sprint planning basics set you up for success

Antonia V.
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 28, 2019

[Click To Tweet]

What I’ve learned from working on a scrum team is that the most successful sprint planning happens when there are distractions that prevent the team from focusing on the task at hand are kept to a minimum.

One way to achieve this is for the Product Owner (PO) and Scrum Master (SM) to work together to groom the backlog before the rest of the team joins them to plan the sprint. This helps keep the sprint planning meeting that follows on track, because the PO and SM can decide preemptively which work is the more important to the project and put this work at the top of the backlog. Work that is less relevant can be placed at the bottom of the backlog, which keeps it from being focused on by the team during the planning session. What I’ve found is that if this is accomplished before a sprint planning meeting, less time will be lost during the meeting debating as a larger group on which work is relevant.

Another good tip is to include a quick description of the sprint planning agenda, along with links to the user stories that are being considered for the upcoming sprint, in the meeting invitation. This way the dev team can have some context and will have time to think about how the upcoming sprint might go and any relevant information they might want to bring up in the meeting before the meeting itself.

During the sprint planning meeting, I’ve found that a good rule of thumb is to set aside at least an hour at the beginning of the week (or 2 hours for a 2 week sprint). This ensures that the team has enough time to figure out what needs to be done and plan carefully. I’ve found that sprint planning meetings that happen early on in the week are more effective, as that way the goals of the sprint remain fresh in the teams’ minds throughout the first week of the sprint, and the work flow isn’t disrupted as much by thoughts of weekend adventures.

My final tip is to keep sprint planning time separate from other things such as retrospectives. It’s easy to get distracted talking about what happened in the last sprint and not have enough time or focus to talk about the upcoming sprint.

Happy planning!

1 comment

We follow all of these techniques and it works well for us. One more thing we do (which I'm curious if you think is good or bad) is that the PO and SM also do rough estimates in their backlog-grooming session to get a little past the velocity (so when we send the agenda out, we can define that we're looking at these issues - sometimes we just set the sprint up without starting it as a prerequisite to the meeting). Of course the team has the option to debate and adjust times, but it helps box in huge backlogs.

Antonia V.
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 28, 2019

That's a good question. I think it partly depends on your team's dynamic, as you want to avoid creating an "us vs. them" mentality between the dev team and PO/SM. The PO should prioritize the work in the sprint meeting, but the team should select how much work they can do for each sprint. I don't think I would go so far as to have the PO/SM set up a sprint before the meeting, as it somewhat infringes on the concept of the self-running team. I would also make sure that in sprint planning meetings the development team's time estimates are always taken seriously and acted upon, along with their thoughts on how much work they think they can accomplish during the sprint. At the end of the day, they are the ones doing the work and it can be difficult to make those estimate from an outside perspective. 

Like Bridget likes this


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events