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::
At the Buffet table, guests serve themselves.
Developers (ideally) PULL the work-items themselves.


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-slices 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 would be liked and appreciated most by the Market.
What work would create maximum value for the Market, and hence for the Product, for their own Organization, and hence for themselves.

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 (more than the planned duration) to finish the pulled work-items, they take that time 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 that your plan was accurate and your schedule variance is zero. 

6::
And here is the most important similarity.
Guests can very well use their judgment about how big/small 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 with their preference for a complicated approach. 

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