The value of Sprint Planning
What happens when you don't do Sprint PlanningMaybe 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.
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 badDisclaimer: This is about "Sprint Planning", not about planning.
Commitment versus Intention
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.
BoredomSprint 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.
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.