The Purpose 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.
Enrol for the Agile Scrum Master Certification training now by clicking on the link below: