Learn the Scrum Rules of Play

This is part 2 of 3 posts on Scrum. Part 1 of this post is Self-organize using Scrum.

The power of Scrum is that it is such a simple framework. To describe the Scrum process just 12 concepts suffice, divided as:

• 3 roles
• 4 work products
• 5 time-boxed events

Within a Scrum Team, Scrum recognizes three roles as depicted in Figure 13.

Figure 13: Scrum Roles

Each of these roles is responsible for a part of the management responsibilities within the Scrum Team. The Product Owner represents all Stakeholders toward the Self-organizing Team. He organizes requests for new or changed functionalities throughout the project, incrementally accepts the evolving solution and decides when increments of the solution go live. He spends some 20% to 30% of his time with the team. An equal amount of time is spent interacting with stakeholders. This role is best played by someone from the business, who will benefit most directly from the solution the team is developing. The Scrum Master facilitates the Self-organizing Team and the Product Owner and in that way ensures that they adhere to the Scrum values and practices. He helps them to understand and use self-organization. The Self-organizing Team consists of developers (in the broadest sense of the word) and subject matter experts who together translate business requests into a usable solution. They provide the Product Owner with estimates, forecast the work that can be done and organize themselves to get it done.

The four Scrum work products represent work to be done or value. They provide transparency in future work, work in progress and work that is done in the sense that it has led to a Usable Increment of the solution. Figure 14 shows these work products within an outline of the Scrum process consisting of the Sprint cycle and the daily cycle. The Sprint cycle represents a time box or iteration in which a Usable Increment of the solution is developed. The Daily cycle represents activities that are repeated on a daily basis.

Figure 14: Scrum Work Products

The Product Backlog is an ordered list of stories that represent requests for new or changed functionality that mean future work for the team. It is maintained by the Product Owner. The input for the Sprint cycle consists of stories from the Product Backlog which are ‘Ready to Poker’. This means that the team knows what the story is, how to realize it in software, which tasks they have to perform, and how it will be accepted by the customer. In other words, if the team is able to estimate (or poker) an item, it is Ready to Poker. The Definition of Done provides a shared understanding of when a story is done. The Product Backlog and the Definition of Done provide important input enabling the team to forecast what can be developed this Sprint. This forecast is represented by the Sprint Backlog. It contains the stories the team selected from the top of the list and details the work needed to get the stories Done. The goal of every Sprint cycle is to develop a Usable Increment of the solution.

The Scrum process consists of five time-boxed events that are repeated throughout development and provide a basis for inspection and adaption. Figure 15 shows these events within an outline of the Scrum process. The Sprint cycle is an event that encloses all other Scrum events. It is a timebox of two to four weeks. Keep the Sprint length constant for at least a few months and gather experience with it before trying out a new one. The timebox indications for events that start and close a Sprint (the ones in hours) are based on a Sprint length of 3 weeks. A Sprint length we have had good experiences with. Adjust them linearly when using longer or shorter Sprints.

Figure 15: Scrum Events

Every Sprint cycle starts with the Plan the Sprint event that consists of two meetings. Within the Sprint Planning Meeting the Product Owner and the Self-organizing Team sit together to select stories for the Sprint from the top of the Product Backlog (more in Section 6.2 Estimation and Planning of Stories). The Product Owner provides the team with input on ordering of stories and the need behind them. The team can negotiate a change of order (based on technical dependencies or technical risk) and provides the Product Owner with their estimates. The Product Owner has the final say in the order in which stories are implemented. The team decides on the forecast of stories that can be implemented this Sprint. In the Work Breakdown Meeting the team details the work that will have to be done to implement the stories (more in Section 6.1 Estimation and Planning of Tasks). After this meeting the team gives its final forecast. These two meetings produce the Sprint Backlog.

Every day the team gets together for a 15 minute Stand-up Meeting at the Task Board to discuss progress. This meeting is meant to minimize the need for other team meetings. Every team member tells what he has done and learned yesterday, what he is going to do for the team today and if there are any impediments holding him back, he needs help with.

As shown in Figure 15 at the end of each sprint two events take place. Review and Demo the Sprint Result is about updating the Product Backlog with insights from the last Sprint (remove stories that are done, re-estimate stories that are partially done or better known now). It also encompasses a demo by the team of the Usable Increment. For the demo the team and the Product Owner invite management and a wider range of stakeholders then the ones directly involved in development. The Product Owner concludes the demo with a presentation of the work still to be done toward the goal and his plan for getting it done. The updated Product Backlog and the current team (development) velocity form the input for this plan. Look Back and Improve is about making a plan for improvement in the next Sprint, focused on what the team can do to improve. What went well? Let’s keep doing that! What could be better? What will we try next Sprint as a team to improve.

Part 1 of this post is Self-organize using Scrum.
Part 3 of this post is Be Transparent.

Other Relevant Posts: 
Introducing Agile
The Agile Spirit

Maintain Stability using XP