Sprint Planning

A few topics (actually quite a few topics) are made unduly complicated in “A”gile circle.  
Sprint Planning is one of them.

Look at these folks enjoying a well-laid-out buffet spread. Guests have a look around the buffet table, they see what they would like the most among the options, and then they serve themselves keeping in mind what size of portion they would happily consume.  

To me, Sprint Planning is not (and should not be) more complicated than helping yourself to a buffet meal.
In fact, I see quite a few similarities between two. 

1::
Guests serve themselves at the Buffet table.
Developers (ideally) PULL the work-items themselves.
A work-item can be 
a) Big fix: the earlier the better.
b) Spike: at times, this is also required.
c) User Story Slice: but never a complete User Story.


2::
Guests have the liberty to pick a small/big portion from any food bowl, keeping in mind what portion they can eat happily.
Developers pull vertical-slice(s) of User Stories, keeping in mind how many slices they can finish within an iteration while abiding by the established DoD.
{After all, there is no point vertically slicing a UserStory, but not building it slice by slice} 

Here is what Ron Jeffries thinks about building it slice by slice.

3::

Guests select food by considering what they like most. 
Developers pull work items, keeping in mind what work they can finish with reasonably good confidence.
And sometimes, just like the chef recommends a signature dish, the Product Manager guides the developers towards work items that would create the greatest impact.

Just as each dish is clearly labelled, the Product Manager and the Architect keep the Product Backlog well refined and the User Stories well sliced, making it easy for developers to understand and confidently pull work items.

While walking to their table with their plates in hand, guests should look happy.
When the sprint plan is made, the developers should feel confident.

Good Sprint Planning begins long before the Sprint Planning meeting. Product Backlog Refinement is where most of that work happens.
In fact, 80% of the sprint planning work must be ready before the sprint planning meeting starts. 

4::
If the guests need 5-10 mins more (more than what they thought), to finish their meal, then they generally take 5-1o more mins, rather than throwing away the plate with the remaining food because the time is over.  

If the developers need 2 days more than the planned duration to finish the pulled work-items, they take that time without feeling guilty to finish the pulled work-items.

5::
When a guest feels the pudding is exceptionally good, and she wishes to have one more small portion, she certainly does that.
If a developer finishes the work-items she had already pulled for the sprint, and if she feels confident that she can finish one more work-item, then she can pull additional work in the same sprint too.
After all, the market appreciates how well you serve them.
The market has zero interest in knowing how accurate your plan was, and your schedule variance is zero. 

6::
Guests don't pick food that someone else must partially eat before they can continue.
Developers should avoid pulling work that is heavily dependent on another developer.

7::
And here is the most important similarity.
Guests can very well use their judgment about how big/small a portion of food they should serve themselves.
A developer can also use his/her educated guess (aka guesstimate) to pull just enough slices in the sprint so that she/he can finish the work with the agreed DoD.

But then, many teams do not like this simple approach of Sprint planning. 
And they love to make a big event out of it, which is appropriately called a “Ceremony”. 
I am not surprised by their preference for a complicated approach. 

As Edsger Dijkstra (winner of the Turing Award in 1972) famously said… "Complexity sells better".