Stephen Covey’s story about the “big rocks” is well known. In brief, a teacher shows her students a container, and fills the container with fist-sized rocks. She asks, “Is the container full?” The students answer, “Yes!” Then the teacher pours in sand. “Is the container full?” Now the students are wiser, and answer no. Then the teacher pours in water and declares that the container is full. She asks, “What is the lesson?” One bright student responds, “You can fit a little more in the bucket!” The teacher responds, “No. The lesson is that unless you put the big rocks in first, they will never fit.”
At first glance, the story is very simple and seems obvious for everyone. On the other hand it is a powerful metaphor describing the sense of life being. Unfortunately human capacity, as well the capacity of our teams and organizations are limited to some natural bounds. It is extremely hard to extend them. We’d better focus on making most important and valuable things first. Otherwise we can get lost in the midst of less important things that can fill up all the capacity («sand»). This is true both for the human life and also for the product development.
How can we use the lesson from Stephen Covey in Scrum? What can be our Big Rock choices in Sprint Planning? Luckily, there is an embedded mechanism for supporting Big Rocks choices during and it is called the Sprint Goal. Scrum Guide describes it as the «objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment».
Big Rocks are those most important Product Backlog Items that support our Sprint Goal. During the Sprint Planning select several Big Rocks (they don’t really have to be that big in size, just very important for implementation) depending on the current Definition of Done, Capacity and Velocity, Retrospective Commitments and possibly other bounds that limit the ability of the Development Team to perform in the upcoming Sprint.
No cheating allowed - don’t try to declare every single Product Backlog Item you take into the Sprint as a Big Rock. From my experience the Big Rocks should take no more than 50-80% of all the «features» list the Development Team takes into the Sprint. Focus on the Sprint Goal through the Sprint and let it be your loadstar. It provides flexibility for the Development Team. The «sand» or smaller rocks can be changed, replace or even thrown away during the Sprint, but no changes should be made that would endanger the Sprint Goal and thus the Big Rocks.
