What’s the purpose of planning?
At first glance, planning a complex, uncertain process might seem totally illogical. How can we plan something that we don’t know so many things about? Despite problems, planning is worth doing, as it enables us to set a goal, reduce risk, and make use of resources we have at our disposal. Let us have a look at the first Scrum event: Sprint planning.
What’s Sprint planning?
A Sprint is a container for all the Scrum events – the opportunities to inspect and adapt our work. First comes Sprint planning. Despite having an adaptive approach to managing product of high uncertainty, Scrum didn’t abandon planning whatsoever. Planning work is said to be more important than the work itself. What’s the point of planning that goes awry anyway? We need to establish the “what” and the “how”. Regardless of changes arising, we need to define our work. The difference is with Scrum we kind of re-plan, re-arrange stuff as we know more about the product, which is followed by a constant inspection & adaptation cycle. That’s called the refinement of the Product Backlog.
What does the 1st Sprint planning look like?
Sprint planning is limited to maximum 8 hours for a monthly Sprint. In Scrum we try to adjust the amount of time to the capability of the team as well as the amount of work to be done, and not the other way around. Sprint planning consists of two main phrases: setting up the Sprint Goal and selecting the Product Backlog Items that support it.
Phase 1: Set up the Sprint Goal
For each Sprint the goal is created. Importantly, it must be aligned with the Product Goal, which is defined as a future state of the product. To dumb everything down, we might say the Product Goal breaks down into a number of Sprint Goals. Sprint planning initiates each Sprint and the whole Scrum Team should participate in it. If needed, the Scrum Team might invite other people to provide advice. Although it’s the Product Owner who’s the product vision provider, they create the goal for each Sprint in collaboration with the rest of the team. Also, the Product Owner explains and translates a business need to the team so that they have a better understanding of the product.
Phase 2: Breaking down the tasks – the pull system
Once the Sprint Goal is established, the Product Owner in liaison with the developers select the items from the Product Backlog that support the Sprint Goal. Then the PBI are broken down into smaller units: tasks. It would be great if tasks were completed within one day. How the developers will do the tasks is left to their discretion. What’s important is they don’t plan the work for the whole Sprint. They rather self-organize their work on a daily basis by pulling a task from the SB and work on it to completion. Scrum follows the pull assigning-task system. Just as Scrum does, the pull model maintains all work in a common queue for developers to be taken.
