The Goal of Sprint Planning

Naturally the goal in sprint planning is to plan a sprint that the team can successfully complete. Some teams will consider a sprint successful when the sprint goal is achieved. But not all teams are able to confine their sprints to a single goal; those teams may consider a sprint successful if team members complete all planned backlog items within the sprint.

But should teams strive to be successful in these ways every sprint?

70–80% Is a Win

No, they shouldn’t. If a team meets its goal or finishes all backlog items every sprint, that probably means the team is playing it safe when planning the sprint. Some teams are conservative in what they choose because of their own natures. Other teams are reluctant to disappoint stakeholders, so they assume an attitude of under-promising. Still others are fearful of being in trouble if they don’t successfully finish what was planned.

I advise teams to get their sprints right 70–80% of the time. If a team does what they say they will at that rate, this gives the organization plenty of predictability. Stakeholders can be told about the plan for the next sprint and reasonably believe the team will likely finish what they’ve planned.

Reasonable stakeholders will understand the sprint plan is not a guarantee, but that it is very likely. If I tell a friend I’ll meet him for dinner at 6:00, he knows I’ll very likely be there on time. But it’s not a guarantee. I’m not going to begin the drive from my house early enough to account for unexpected traffic, getting stuck at a train crossing, having a flat tire, and road construction that causes a detour, all on the same journey.

Finishing 100% of the work 70–80% of the time, allows a team to more aggressively plan each sprint. An item that might be achievable during a sprint now gets included. The same item would have been left out in a culture in which everything must be finished every sprint.

Setting a goal of getting it right most sprints, rather than every sprint, also enables teams to conduct planning meetings more quickly. Saving time in meetings is always a win in my book.

What About When a Guarantee Is Needed?

There are times when stakeholders do need a guarantee of what will be delivered in a sprint. What should a team do then? In those cases, the team has two equally viable options.

First, team members can plan a sprint that includes only what they feel very confident they can deliver. In an example above I wrote that a team might bring an item into the sprint if they thought they could complete it but weren’t sure. If a guarantee is needed, they wouldn’t bring that item into the sprint.

Alternatively, the team can commit to some items in the sprint and identify others as stretch goals that may or may not be included.

What Do You Think?

Do you agree with me that a team should not target finishing everything or achieving their sprint goal every sprint? How often does your team achieve their goal or finish everything? If it’s 100%, do you think team members are sometimes playing it safe so they finish everything? Please share your thoughts in the comments below.


Get Your Customized Elements of Agile℠ Assessment

Get Your Customized Elements of Agile℠ Assessment

Find out how your team is progressing in their mastery of the 20 key Elements of Agile.

Posted:

Mike Cohn

About the Author

Mike is CEO of Mountain Goat Software, and one of the industry’s most well-respected Certified Scrum Trainers. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. He is a co-founder and former board member of the Scrum Alliance, and a co-founder of the non-profit Agile Alliance, home of the Agile Manifesto.

With 20+ years of agile training experience, Mike has honed a talent for explaining agile concepts with clear illustrations and real-life examples. Participants enjoy his passion for teaching the agile methodologies in a relatable and digestible way. 

Scrum Certifications include: CSM, CST, CSPO, A-CSM, CSP-SM, CSP-PO