What is Scrum?
It is an iterative methodology that treats major portions of development as a controlled black box. Iterations called sprints (described in more details later in this article) are used to evolve the product which is ready to ship after each sprint. This is different from the traditional way to build software, used by companies, which was a sequential life-cycle commonly known as “the waterfall.”
A methodology originally refined in 1995 by Ken Schwaber and Jeff Sutherland, from work done by Hirotaka Takeuchi and Ikujiro Nonaka. Named after the SCRUM in Rugby, this is the most recognized agile framework.
The agile family of development methods was born out of a belief that an approach more grounded in human reality and the product development reality of learning, innovation, and change – would yield better results. Agile principles emphasize building working software that people can get hands on quickly, versus spending a lot of time writing specifications up front. Agile development focuses on cross-functional teams empowered to make decisions, versus big hierarchies and compartmentalization by function.
The Scrum Team
A Scrum team is composed of a product owner, Scrum Master, and development team, responsible for the high-quality and timely delivery of sprint commitments.
The Product Owner - Takes the inputs of what the product should be and translates them into a product vision or a Product Backlog.
The Team - Develops the product envisioned by the Product Owner.
The Scrum Master -
Does whatever it takes to make the Scrum Team successful, such as removing organizational impediments, facilitating meetings, acting as a gatekeeper so no one unnecessary interrupts the team's work.
Sprint
Cycles of work are called Sprints. These iterations are no more than 3 to 4 weeks each, and take place one after the other without pause. The Sprints are time-boxed – they end on a specific date whether the work has been completed or not, and are never extended.
At the beginning of each Sprint, a cross-functional team selects items (customer requirements) from a prioritized list. The team commits to complete the items by the end of the Sprint. During the Sprint, the chosen items do not change.
Every day the team gathers briefly to inspect its progress, and adjust the next steps needed to complete the work remaining. At the end of the Sprint, the team reviews the Sprint with stakeholders, and demonstrates what it has built. People obtain feedback that can be incorporated in the next Sprint.
The output of every Sprint is officially called a Potentially Shippable Product Increment. Before the first Sprint, the Product Owner and Team need to agree on a Definition of Done, which is a subset of the activities that are needed for creating a Potentially Shippable Product Increment. The Team will plan their Sprint work according to this Definition of Done.
Sprint Events
Before starting any sprint event the first step in Scrum is for the Product Owner to evolve product vision into a refined and prioritized list of features called the Product Backlog.
Sprint Planning Meeting
At the beginning of each Sprint, the Sprint Planning Meeting takes place.The work to be performed in the Sprint is planned in this meeting. This meeting is typically divided into two parts (part one is “what” and part two is “how”).
- What will be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
Participants:
Part One: Product Owner, Team, ScrumMaster. Part Two: Team, Scrum Master, Product Owner (optional but should be reachable for questions)
Duration: Each part is time-boxed to one hour per week of Sprint.
The Product Backlog items selected for this Sprint, plus the plan for delivering them is called the Sprint Backlog.
Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team (Product Owner is optional, ScrumMaster is usually present) to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.
Every day, the Team members update their estimate of the amount of time remaining to complete their current task in the Sprint Backlog. Following this update, someone adds up the hours remaining for the Team as a whole, and plots it on the Sprint Burndown Chart. This graph shows, each day, a new estimate of how much work (measured in person hours) remains until the Team’s tasks are finished. Ideally, this is a downward sloping graph that is on a trajectory to reach “zero effort remaining” by the last day of the Sprint.
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.The result of the Sprint Review is a revised Product Backlog (a.k.a. Product Backlog Refinement) that defines the probable Product Backlog items for the next Sprint.
The Sprint Review includes the following elements:
- The Product Owner identifies what has been “Done” and what has not been “Done”;
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.
This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.Time-boxed to 45 minutes per week of Sprint.
The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.
To know more about scrum and CSM training, click here.
References: -
- Jeff Sutherland’s Scrum Handbook, published by The Scrum Training Institute.
- The Scrum Primer, 2012, by Pete Deemer, Gabrielle Benefield , Craig Larman , Bas Vodde.
- The Scrum Guide, 2013, by Ken Schwaber and Jeff Sutherland, published by scrum.org.
