Sprint Planning, First segment — A Customer Gang Bang (With Healthy Side-effects)

This post covers the benefits of the first segment of the Sprint Planning meeting. It relies on the previous post (a quite boring elaboration on the details of the Sprint Backlog).

The Sprint Planning meeting is time-boxed to 8 hours, and consists of two segments that are 4 hours each. The first segment is for choosing Product Backlog-items to commit to, and the second segment is detailing the Sprint Backlog.

First segment : People. Talking. To one another! About the project requirements!! And goals!!! Woho.

The Team with its facilitator (The Scrum Master) and the customer (Product Owner) are all present in the first segment. The Product Backlog has been prepared by the Product Owner, and the team chooses items it can commit to, turning it into an potentially shippable iteration of the product.

It is quite a groundbreaking mechanism. People actually interacting with each other to establish common goals. This moment is the materialization of just how low levels of fanciness (or even schmanciness, for that matter) are required for magic to happen. It’s all about the people and their communication. It will stand up to any fancy artifact you can think of introducing in its place.

Thus, this is the big Gang Bang as to what communication is concerned. Continuous goal oriented communication is a cornerstone in all complex undertakings involving human beings. This is the major event for ensuring sustained and rapid delivery of software with real business value. As such it will to be valued a key moment in the project’s monthly cycles. The customer understands the Product Backlog, and is engaging in face-to-face communication with the team. Can you remember when you first had “The Talk” with your girl- or boyfriend? Do you remember how important it was for your relationship? This is “The Talk” of the love-affair that the project represents. You won’t need to invoke physical cravings for the customer himself, but your love for the project will develop your interest in these sessions as the benefits become more and more obvious.

So what is going on under the sheets?

Low priority requirements starve. This is an imperative mechanism of Scrum, and one which I have visited on several occasions already in this blog. Presenting the customer with the Product Backlog evolves his insight into what can and what cannot be done immediately. It will be obvious that, as we are only planning for one month, we’ll only choose a limited amount of requirements to commit to. If new Product Backlog items makes it into the list before the next monthly Gang Bang, the customer will intuitively understand why some of the low priority items are starving at the bottom of the list, not making it into the sprint. The power of a lean priority focused work-flow work will become obvious. The focus becomes fierce and healthy, and most important, it becomes apparent and intuitive.

I like to think of this mechanism as a similar mechanism that makes great poker players great. They maximize winnings on their good hands, and minimize their loss on bad hands. Scrum helps you focus fiercely on the good requirements (maximize winnings) and minimize focus on the “bad ones”, which no-one ever wastes time planning or talking about (minimize loss). It’s a killer combination. The great poker players are sure to be good intuitive “Scrummers”.

Or, as the agile movement so bluntly states it: Simplicity — the art of maximizing the amount of work not done — is essential. (Agilemenifesto.org)

Why the 4 hour time-box? It takes only a small amount of time to introduce problems that sums up to a months worth of solving. Adding more time does not solve this problem, it adds to it. This is realized both by understanding how much simpler it is to state “I want to fly to the moon on a carpet covered with rose-leaves” than actually going through with it. Also the number of implicit requirements (related requirements discovered during planning or development) will increase (or explode) during the second segment of sprint planning, and during The Sprint itself. By avoiding the strive for perfection during this planning phase, we just might increase overall perfection for the project.

I’ll elaborate on the second segment of Sprint Planning in a future post.