When a project starts, Scrum based teams are challenged with transforming the the chrysalis of a charter or RFP into the butterfly of a Product Backlog. The pressure of this challenge is even greater when delivering under a fixed priced project. The last thing a team needs is the distraction of explaining the mechanics of Scrum to business partners such as the Product Owner. Therefore, it is imperative that a clear plan for Sprint 0 (or the Discovery period) is layed out so that all participants are clear on their roles and the process of narrowing the cone of uncertainty is undertaken as soon as possible.
Sprint 0 Participation Matrix
When planning for Sprint 0, we use a matrix like the one below to help our clients understand what their involvement will be during the discovery period and who needs to be invited to the meetings. (R=Required, O=Optional)
Sprint 0 Activity Details
We start Sprint 0 with a Kick-off meeting. This is where the team introduces the mechanics, artifacts, roles and ceremonies of scrum to interested parties. This meeting is important to help familiarize stakeholders with not only the people producing the software, but some of the terminology that may not be familiar to them.
Project Management Planning
It is often the case that a project is conducted with partners that are not familiar with Scrum. In those cases we help construct a “translation layer” between the ceremonies and artifacts produced by Scrum that need to be translated to more traditional command and control communications. During these activities, we seek to to inform our business partners how to take the information produced by the project team (such as a Burndown Chart) and use it to drive overall milestone progress.
Scrum succeeds when the project team is able to show value to stakeholders and get feedback on what they produced early in the project. Therefore, it is very important that the Product Owner understand the responsibility of prioritizing the Product Backlog so that the most important functionality is produced first.
This is why the User Stories on the Product Backlog are expressed solely in terms of business value. The project team works with the Product Owner to make sure that User Stories only contain brief statements of functionality that help users achieve their goals. We also ensure that the User Stories are right sized so as to avoid epics listed at the top of the Product Backlog. The stories at the top of the Product Backlog should always be sized so that they are discreet enough and understood well enough for the team to begin construction on them during the next sprint.
Project Team Planning
Scrum requires an unambiguous status with regards to the completion of functionality. Therefore, at the outset of the project, the team must establish what it means to be “done.” Doing so involves working with business partners and the IT organization to understand both the functional and non-functional requirements required to consider a piece of functionality to be potentially releaseable.
Once this understanding is in place, the team can begin to estimate the relative size of each User Story in the Product Backlog. Typically, we use Story Point estimation and, when there are a large number of stories, the best way to go about this is to do a relative comparison. This process starts with establishing a small, medium and large sized story and then comparing each story in succession to the sample stories deciding whether they are bigger or smaller.
The final step of Sprint 0 is for the Project Team to produce a sample piece of functionality. This activity has several goals. It prepares the team for Sprint 1 and enables them to “hit the ground running” by making sure all of the pieces are in place for a successful launch. It demonstrates to stakeholders that the team is capable of producing live working software. And most importantly, it helps establish an initial velocity for the team.
Velocity is expressed as the number of story points completed during a time-boxed duration. While teams do tend to improve as they work together inside a problem domain, establishing velocity coming out of Sprint 0 allows them to begin to answer the question of how much they can finish within the given constraints of time and budget. If, for example, a team consistently completes 20 story points during a three-week sprint and the remaining Product Backlog contains a total of 200 story points, we can predict with an acceptable amount of risk that it will take them 10 sprints or 30 weeks to complete all of that functionality.
However, should the budget only support 15 weeks, the Product Owner can begin to plan around a “red line” commitment that the team will complete 100 story points worth of functionality. While the red line may come as a disappointment for some Product Owners, it is important to remind them that since the most valuable features are developed first and that upwards of 60% of software features are either rarely or never used, it is most often the case that sufficient functionality will be ready for go live.
The final event of Sprint 0 is a Scrum Sprint Review in miniature demonstrating the deliverables of the Discovery period.