By Roman Pichler
When was the last time you came across a project that was not urgent? I can’t remember my last time. This probably explains why many Scrum projects I have worked with were tempted to kick off the first sprint without having fully thought about the necessary prerequisites. This article discusses the minimum set of preparation activities required to ensure that your Scrum project is set up for success.
Ready …
While you want to minimize your preparation activities to start delivering shippable product increments as quickly as possible, some setup is required. If you skip the steps below to save time, you are likely to experience a lower project velocity overall.
First and foremost, the right people have to be on board and the Scrum roles have to be properly filled. That means that the product owner, the team and the ScrumMaster are available to start working on the project; the team has the right performers on the team to create shippable increments reliably; and everyone involved understands how Scrum works.
Second, the product backlog has to be initially stocked and prioritized. The product backlog should contain at least two to three sprints worth of work. For innovative, critical, or complex projects, the backlog should be as completely stocked as possible. Notice that requirements are described at different levels of granularity in Scrum, which allows the upfront requirements effort to be reduced to a minimum. Holding requirements workshops is a great way to collect requirements and to allow the product owner, team, and end customers to interact.
Third, the development and test environment must be ready. If the environments are not in place, the team cannot create shippable product increments. Remember: Every increment in Scrum must implement a subset of the requirements into software, and must be adequately documented and tested.
Fourth, the team has to know how the requirements stated in the product backlog can be transformed into shippable product increments. For a new product development project, this may entail some organized experimentation, including the creation of prototypes (spikes) and models. If more experimentation is required, the related activities should be carried out within sprints of their own right. (I will say more about applying Scrum on new product development projects in a future column.) A team working on a maintenance project typically has to read the existing documentation and explore the code base.
Steady …
Once the steps above have been completed, four more preparation activities are necessary to have a successful, short and focused sprint planning meeting. Notice that these activities tend to occur before every sprint planning throughout the entire project:
The team estimates the product backlog items. The very first effort estimation workshop is likely to last longer, as participants try to cover as many items as possible. Try to avoid workshops that last longer than four hours, though, since the concentration of the team tends to rapidly deteriorate in my experience. As part of the preparation activities for every sprint planning meeting, the team estimates any new requirements. This allows the product owner to determine whether the requirements are fine-grained enough to be transformed into a product increment within a sprint and understandable for the team or if they need be broken down and worked on further. Additionally, the team gets a preview of what’s ahead.
The product owner identifies a sprint goal and discusses the related product backlog items with the team. Remember that in Scrum, the team members have five percent of their time available to help the product owner refine requirements, discuss acceptance criteria, and estimate new requirements prior to the sprint planning meeting. If you use two-week sprints, this amounts to half a day. Having this discussion prior to the planning meeting avoids unpleasant surprises that can lead to a stressful or even unsuccessful planning meeting. Don’t forget: All meetings are time-boxed in Scrum.
The team determines its availability. This includes identifying the net hours team members have available to work on the project for the upcoming sprint.
The ScrumMaster prepares the meeting. This includes booking a suitable venue to hold the sprint planning meeting and the preparation of facilitation material required. I very much prefer planning meetings away from phones and email in properly set-up meeting rooms and the use of low-tech tools such as index cards for task identification to ensure full participation of everyone involved. Notice that the first sprint planning meeting is likely to take longer, particularly if the team is new to Scrum. Make sure that you guide the team properly and explain the sprint planning steps so everyone is on the same page. And don’t forget to keep the time!
GO!
You have set-up your project for success and you are ready to start the first sprint planning meeting now. Well done. Good luck and enjoy!
