The biggest gripe agilists have with "traditional Waterfall" projects is "Big Upfront Design", or, in short: BUFD. Many detailed design documents are full of feature requests that were just put in "in case we might need it". When the specification goes into development, there's too many trees to see the forest and people lose perspective of what is really important because a contract has been agreed to deliver everything. As a consequence, when time runs short, the customer oftentimes ends up with a half-baked software that has lots of fluff but lacks essential features. As the Standish Group Chaos Report states, the consequence is often colossal failure.
The value of Sprint Planning
Sprint Planning is an important discipline of Scrum. The main outcome of Sprint Planning is setting a short-term objective for the next sprint. The team and stakeholders agree on what will be covered, why - and in which order. On the positive
side, the information gap between development and business is minimized.
On the negative side, unrealistic expectations and bad ideas are weeded
out before any effort is wasted.
Many teams use "Planning Poker" and "Story Points" to determine how much they are capable of delivering.
What happens when you don't do Sprint Planning
Maybe 100 years ago it was possible to go to Klondike with nothing but a pickaxe and make a fortune. However, that was unreliable and many found their demise rather than wealth and glory. Those who want to succeed lay out a plan, stake the best claims - and replan early when their assumptions turn out wrong. And this is what we should be doing in agile as well.
We use the Sprint Planning to determine
where the value lies and where it's worth to lay a claim and mine the
gold. Continuing in this figure, we determine how rough the terrain will
be, how deep we will dig and what tools we'll use to bring forth the wealth.
Everyone wants to deliver high quality working software with maximum value. It makes developers proud for a job well done, customers happy to work with the product - and business happy because money is received.
Why having Sprint Planning is bad
Disclaimer: This is about "Sprint Planning", not about planning.Commitment versus Intention
Many immature organizations consider Sprint Planning as a way of retaining some illusion of control. Developers are asked to commit to completing the Sprint's stories and held accountable to meeting their quota. Note that this is a misinterpretation of the intention: The team commits to what they will be working on in terms of direction and focus, not in terms of quantity!
Committing to a plan
It's easy for the team - or Scrum Master - to stand up and say "You want a change? We can make a change. But we'll terminate the sprint, discard the efforts up until today and restart." This creates an atmosphere of fear. Stakeholders become afraid and developers unwilling to make "just in time" changes.
A sample perhaps? At the beginning of the Sprint, we said we need a button "More details" on the product display. While implementing it, we realize it won't deliver value: We need a "Buy Me" button instead!
Who will muster up the courage to terminate the entire Sprint for a useless button? Nobody. And so, we let the developers waste time to build a worthless feature and put another story into the product backlog so that in maybe 3 week's time we get a valuable feature that could be available in a day's work.
And what happens next? In the Review, developers proudly demo the worthless function to a disgruntled marketing department who aren't even interested any more and end users who ask "Why would I want this?"
Wouldn't it be significantly better to have a mechanism "I realize we don't need X, let's just discard it and do Y instead"?
Yelling "Scope Creep!"
Sprint planning has the intention of determining the scope of development in a sense that developers are aware what defines "success" for this sprint. Many teams will - unfortunately - go as far as to deliver exactly the committed Acceptance Criteria and nothing else.They may not account that users, just like they themselves, are often uncertain on what the final product should look like. Yes, it's good to have a clear picture of the outcome before starting.
Let's be picturesque again.
When you go to an interior architect, they often create a fully explorable 3d model of your future living room before ordering a single tile and let you review and adjust the placement of every single object in real time.
What you may just be doing is asking the customer to come up with a fully explorable 3d model of their future living room - not giving them the opportunity to review and adjust the placement of any single object for a full sprint. And much less would you give them the opportunity to ask "While we're putting up this deco fountain, would an ivy plant would look nice here?". And even less would you suggest it by yourself, because hey, that's Scope Creep!
Even if planning not used to keep the customer out of the development process, it is better to make just-in-time adjustments than to defer the delivery of visible value.
Boredom
Sprint plannings are bulk sessions. All topics relevant in the sprint are bundled up together and in a meeting marathon that may well take a couple hours, one topic after the other is covered.
The worst part of this is that as the meeting progresses, interest wanes. Obviously, a well groomed backlog would put the lower-valued topics later in the plan. However, even the last item of the backlog is still the most valuable item the team can work on from all topics to follow.
Team members and stakeholders will not be discussing and estimating the 7th user story in a row with the same level of attention and fervour as they discussed the 1st story. As such, the risk of lapsing ideas increases as planning progresses.
It is good to have a clear plan for the sprint, but it is better to not overburden anyone and keep the discussion fresh and vital.
Hiding behind a curtain
We planned 4 stories, we delivered 4 stories. Everything is good.
Is it? One story was 2 man-days, another was 15. It should have been an Epic, sliced into multiple bite-sized portions. The timebox may become a curtain veiling the true complexity of individual stories. Stakeholders may lose the valuable opportunity to refine the "MVP" of a story as it starts to become unexpectedly complex during a sprint.
Planning provides a direction. It should not replace the opportunity to re-negotiate every single story during the implementation phase. The value of software development can be multiplied by a magnitude when during the development of each line of code, Inspect+Adapt is applied. This may well include scrapping and reworking committed Acceptance Criteria mid-implementation.
It is good to make a plan with the stakeholders before getting to work. It is better to refine this plan every single day even while completing the work.
Overproduction
Two of the Seven Deadly Wastes identified in Lean is "Overproduction" and "Storage". This is what planning often does.
The team does not know for certain how much they can deliver, but they don't want to be idle, either.
So, sprint planning typically covers 1-2 stories more than the team will actually scope. This may be "pull forward". Given the nature of agile projects, not only the pull-forward, but also the planned scope may not be reached. By the time the sprint ends, objectives may have changed and none of the unfinished stories become part of the next sprint's plan.
Congratulations, you've created a storehouse for undone work and have produced plans that may never come to fruition. Not very Lean.
It is good to have enough items in the backlog to optimize value delivery. It is better to have a mindset in the team that not everything we plan is a commitment.
But it is even yet better to not plan anything that you won't be doing.
By producing a continuous flow of stories "just in time", we prevent the terrible waste of planning and storing story details we will never use.
Summary
There is a reason why "Responding to Change" is considered more valuable than "Following a plan".
Not making a plan is a terrible idea and will devastate the product. But it is better to defer any detailed planning to the latest point in time where it makes sense. The best point in time is "When we are doing it". This will not only be within the sprint - it may be even after we started realizing the story!
Do not use Sprint Planning to lock out the golden opportunity to deliver maximum value.
Use a continuous flow of stories to inspect and adapt whenever it makes sense.