Kayaking Through Sprint Planning
Sprint planning should feel like launching a kayak — calm on the surface, current roaring beneath.
The Analogy
For the purposes of this article, your product manager and tech lead have taken the time to refine; they’ve added every edge case to the acceptance criteria (AC) of each ticket, and the team has agreed on appropriate story points for each ticket to accomplish those ACs.
Now that we have that hypothetical scenario (no matter how unachievable it is to have perfect tickets), how do we take those tickets and plan them out for a sprint? There are some common errors when it comes to sprint planning, and I think they parallel nicely with the errors a kayaker might make.
TL;DR
If you are one of the few who blindly accept advice without reading the rationale, here’s your section. But the kayak + sprint planning analogy below is fun - so give it a read.
Assess the importance of specific tickets included in the sprint
Make sure the highly important tickets are distributed across all team members so they can work on them in parallel
Pair mission‑critical tickets with your most experienced engineers to protect timelines.
Assign low‑priority tickets to individuals who have less experience in the area
Focus on impact rather than achievement
Don’t aim to close out your sprints with 100 % completion on all tickets (This is the core concept I outline below)
Systematize getting rid of the chaff
Evaluate all overflow tickets (tickets which have carried over from the previous sprint) and remove unnecessary AC or execute on them with priority at the start of the next sprint.
What is sprint planning?
(Skip if this is familiar to you)
Sprint planning is a core agile planning ceremony where teams commit to work for the next iteration. The sprint planning is the assignment of tickets to engineers to complete within the sprint window. It is a key component because it offers the product team insights into what might be completed at which time & it allows them to escalate those timelines to their constituents. It also is the key point where agile offers engineers the opportunity to expand their knowledge. Assigning the same tickets (ie: salesforce tickets always go to Sally) to the same people allows for specialization, but that comes with its own risks.
The completion percentage of these assigned tickets will be used at the end of the sprint to assess the “Sprint Health,” and the story points completed will help the team figure out their relative velocity. These metrics anchor both agile planning forecasts and stakeholder confidence. If your team doesn’t use story points (they can be pretty hotly debated in their value) read my upcoming article on their value & failure points.
Kayak Style Planning: Ride the Current
There is no better comparison (there may be, but I’m unaware of one at the point in time) than comparing the serenity of kayaking to sprint planning. Back in 2010, I went on this sea‑kayaking trip in North Carolina’s Outer Banks. It was my first time kayaking for any long period of time and I didn’t realize how it would help me to understand sprint planning later on in life.
Don’t close out your sprints
Aim for 70–80% completion with your sprint tickets each sprint. When you’re kayaking across a river, you choose a single point on the opposite river bank and you mercilessly aim for it. If you aim directly at it, you’re not going to hit it. You have to take into account the current of the river.
But the river’s current is fluid; it’ll change season by season and even if you nail the current exactly, you still might miss the point because you forgot to take into account the wind.
Let’s say you’re an expert kayaker and you nail both wind and current estimates perfectly; in that situation you may hit the other bank exactly where you’re aiming… but was it worth it to spend the time calculating the exact speed of the wind and the exact change in the current in order to hit a specific point on the other side of the bank?
I doubt it. The same holds true with sprint planning.
With every ticket, you are going to come across situations, edge cases, pieces of the ticket which need to be rewritten, or CSS fluff that doesn’t necessarily lead to a better outcome. Don’t let the idea of hitting all of the AC’s be the overall goal of every individual ticket. If you do, you’re going to over‑plan your sprint.
But engineers (myself included) are notoriously terrible at getting their heads out of the weeds when they start driving through acceptance criteria. In a ticket made of 10 small things, doing the next small things isn’t going to make a terrible difference, but a team of team folks doing one small thing that isn’t really necessary to make sure the kayak hits the other bank isn’t a good use of time.
So how do we force engineers to efficiently prioritize? How do we force them to question the value of AC’s and ensure that their goal is to generate the most impact possible in a ticket following the spirit of the ticket, rather than having a goal of completing each and every AC?
Deliberately over‑commit so the team normalizes healthy, data‑driven misses. Every single sprint, we are going to fail to meet our goal of closing out every ticket. We are going to talk about what we miss, and we are going to see which misses were justified and which need to be carried over into the next sprint. But you should never give them tickets that are expected to be 100% completed. That ensures that you are going to waste time doing things that are not necessarily worth the value.
If we set goals that are not achievable, we are still going to make it to the opposite bank, and then afterwards we can discuss if we can take into account the wind or the current a little more in the next sprint. Not with the goal of reaching 100%, paddling that last 30% is the most exhausting because no matter what you are going to be going against the current at some point. It’s the final‑mile problem of delivery trucks manifesting in the sprint planning process. So over‑plan, under‑deliver, intentionally.
On that kayaking trip, when we hit the other bank, we didn’t care if we landed at the exact point we aimed - we only cared that we landed in the general area we were hoping. And when we missed our that exact point, we certainly didn’t carry our kayaks up the bank to make sure we camped there.
Priorities change and should be re-evaluated, and the process of planning should change too. When you have 1 acceptance criteria absent out of 7 at the end of a sprint, that single acceptance criteria can now be evaluated against the value of the new tickets that can be prioritized. If you are running a quick and iterative agile process, new tickets can be (and should be) prioritized over that missing AC.
But can project timelines be calculated?
Velocity. Even with this strategy, your velocity will not adjust negatively.
We have three driving forces that expedite velocity with this approach.
If an engineer completes tickets early, they know exactly what to work on next.
It fosters healthy conversation during active development about the cost/value of specific AC’s
It doesn’t impact impact planning if velocity used.
The key factor that all product managers should use when planning is velocity. How many story points can the team complete on average every sprint? That value would in no way be adjusted if you over-assign a sprint assuming 80% completion.
As long as the PMs use velocity as the key metric, and acknowledge all tickets planned will not be completed (outside of that velocity), planning is in no way negatively impact.
Conclusion
Hitting an exact point on an opposite bank is a waste of time. Aim at a general area, get there, and evaluate if it’s a good enough spot to set up camp. If it’s not, move a bit, if it is… set up camp and don’t think about it again.
You have basically described part of the engineering cycle summarized as Effort > Output > Outcome > Impact. Management likes to see hard-fast numbers "I put money in, I get deliverables". This is how Sales work. I ask the sales team for POs and I either get them or not (very black and white). And that B&W philosophy is what lead CEOs to ask engineering for metrics. They want to make sure their investment is worth the money. Unfortunately engineering isn't B&W. We may be asked to deliver a feature in 3 sprints and we can do that but the result may be buggy or looks like something from the 1990s or it is half done. That will look bad. But the impact of that half-complete feature may still be hugely beneficial.
Now that example is not representative of all situations and management requests but it asks the question "why do you need these metrics? What do think they show you?" If you want to read a good article that articulates this way better than I just did, checkout The Pragmatic Engineer "Measuring Developer Productivity".