How Scrum works?

Scrum Overview – How does it really work?

How Scrum works

In the following paragraphs, a brief Scrum overview is presented. It provides an explanation as to how Scrum really works in product development, in a few easy steps. You can use this text as a reminder or a guide for everyday Scrum in your organization, especially when you have a new team member.

The Product Backlog

When we start talking about “How Scrum works”, we have to be aware of the fundamentals of the whole product development process. The first step in Scrum is for the Product Owner to articulate the product vision. Eventually, this evolves into a refined and prioritized list of features called the Product Backlog. This backlog exists and evolves over the lifetime of the product; it is the product road map. The subset of the Product Backlog that is intended for the current release is known as the Release Backlog, and in general, this portion is the primary focus of the Product Owner. The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth.

Sprint planning

At the beginning of each Sprint, the Sprint Planning Meeting takes place. It is divided into two distinct sub-meetings. In Sprint Planning Part One, the Product Owner and Team (with facilitation from the Scrum Master) review the high-priority items in the Product Backlog, as well as the “Definition of Done”. Sprint Planning Part Two focuses on detailed task planning for how to implement the items that the team decides to take on. There is no changing the sprint goals during the sprint.

Daily Scrum

Once the Sprint has started, the Team engages in another of the key Scrum practices: The Daily Scrum. This is a short (15 minutes or less) meeting that happens every workday at an appointed time and place. Everyone on the Team attends. In the Daily Scrum, one by one, each member of the team reports three (and only three) things to the other members of the team: (1) What they were able to get done since the last meeting; (2) what they are planning to finish by the next meeting; and (3) any blocks or impediments that are in their way. There is no discussion during the Daily Scrum, only reporting. If discussion is required, it takes place immediately after the Daily Scrum in a follow-up meeting, although in Scrum no one is required to attend this.

Updating Sprint Backlog & Sprint Burndown Chart

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 or relative points) 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. And while sometimes it looks good, often it does not; this is the reality of product development. Then the Team needs to execute the Scrum Emergency Procedure: (1) Change the approach to the work or remove impediments to increase velocity; (2) Get help by having someone outside the team take some of the backlog; (3) Reduce the scope of work; (4) Abort the Sprint.

Product Backlog Refinement

One of the lesser known, but valuable, guidelines in Scrum is that 5-10% of each Sprint must be dedicated by the Product Owner and the team to refining (or “grooming”) the Product Backlog. This includes: detailed requirements analysis, splitting large items into smaller ones, estimation of new items and re-estimation of existing items. This refinement activity is not for items selected for the current Sprint; it is for items for the future, most likely in the next one or two Sprints.

Ending the Sprint

One of the core tenets of Scrum is that the duration of the Sprint is never extended – it ends on the assigned date regardless of whether the Team has completed the work it committed to. A consistent duration helps the Team learn how much it can accomplish, which helps in both estimation and longer-term release planning.

Sprint Review

After the Sprint ends, there is the Sprint Review, where the team reviews the Sprint with the Product Owner. The Sprint Review is an inspect and adapt activity for the product. It is a time for an in-depth conversation and collaboration between the Team and Product Owner to learn the situation, to get advice, and so forth. Present at this meeting are the Product Owner, Team members, and Scrum Master, plus customers, stakeholders, experts, executives, and anyone else interested.

Sprint Retrospective

The Sprint Review involves inspect and adapt regarding the product. The Sprint Retrospective, which follows the Review, involves inspect and adapt regarding the process. A simple way to structure the Sprint Retrospective is to draw four columns on a whiteboard, labelled (1) What went well?; (2) What could have been better?; (3) Things to try?; (4) Issues to escalate? – and then go around the room, with each person adding one or more items to the lists. As items are repeated, check marks are added next to them, so the common items become clear. Then the team looks for underlying causes, and agrees on a small number of changes to try in the upcoming Sprint, along with a commitment to review the results at the next Sprint Retrospective. It’s an opportunity for the entire Scrum Team to discuss what’s working and what’s not working, and agree on changes to try.

Updating Release Backlog & Burndown Chart

At this point, some items have been finished, some have been added, some have new estimates, and some have been dropped from the release goal. The Product Owner is responsible for ensuring that these changes are reflected in the Release Backlog (and more broadly, the Product Backlog). In addition, Scrum includes a Release Burndown chart that shows progress towards the release date. It is analogous to the Sprint Burndown chart, but is at the higher level of items (requirements) rather than fine-grained tasks. Since a new Product Owner is unlikely to know why or how to create this chart, this is another opportunity for a Scrum Master to help the Product Owner.

Starting the Next Sprint

Following the Sprint Review, the Product Owner may update the Product Backlog with any new insights. At this point, the Product Owner and Team are ready to begin another Sprint cycle. There is no down time between Sprints – teams normally go from a Sprint Retrospective one afternoon into the next Sprint Planning the following morning (or after the weekend).

Release Sprint

The perfection vision of Scrum is that the product is potentially shippable at the end of each Sprint, which implies there is no wrap up work required, such as testing or documentation. Rather, the implication is that everything is completely finished every Sprint; that you could actually ship it or deploy it immediately after the Sprint Review.

However, many organizations have weak development practices and cannot achieve this perfection, or there are other extenuating circumstances (such as, “the machine broke”). In this case, “Release Sprint” is needed to handle the remaining work. A goal of any Scrum Team is to minimize the number of Release Sprints for completing “undone” work. Undone work tends to accumulate exponentially and causes poor product quality.

Release Planning & Initial Product Backlog Refinement

A question that is sometimes asked is how, in an iterative model, can long-term release planning be done. There are two cases to consider.

In the case of a new product, or an existing product just adopting Scrum, there is the need to do initial Product Backlog refinement before the first Sprint, where the Product Owner and team shape a proper Scrum Product Backlog. This could take a few days or a week, and involves a vision workshop, some detailed requirementsanalysis, and estimation of all the items identified for the first release.

Surprisingly in Scrum, in the case of an established product with an established Product Backlog, there should not be the need for any special or extensive release planning for the next release. Why? Because the Product Owner and team should be doing Product Backlog refinement every Sprint (5-10%of each Sprint), continuously preparing for the future. This continuous product development mode obviates the need for the dramatic punctuated prepare-execute-conclude stages one sees in traditional sequential life cycle development.

Focus is on creating and refining a plan to give the release broad direction, and clarify how tradeoff decisions will be made (scope versus schedule, for example). Think of this as the roadmap guiding you towards your final destination; which exact roads you take and the decisions you make during the journey may be determined en route.

Application or Product Focus

For applications or products – either for the market or for internal use within an organization – Scrum moves groups away from the older project-centric model toward a continuous application/product development model. There is no longer a project with a beginning, middle, and end. And hence no traditional project manager. Rather, there is simply a stable Product Owner and a long-lived selfmanaging Team that collaborate in an “endless” series of two-or four-week Sprints, until the product or application is retired. All necessary “project” management work is handled by the Team and the business owner—who is an internal business customer or from Product Management. It is not managed by an IT manager or someone from a Project Management Office.

Scrum can also be used for true projects that are one-time initiatives (rather than work to create or evolve long-lived applications); still, in this case the team and Product Owner do the project management.

A basic productivity theme in Scrum is for the Team to be focused on one product or application for one Sprint.

Common Challenges

Scrum is not only a concrete set of practices – rather, and more importantly, it is a framework that provides visibility to the Team, and a mechanism that allows them to “inspect and adapt” accordingly. Scrum works by making visible the dysfunction and impediments that are impacting the Product Owner and the Team’s effectiveness, so that they can be addressed.

Scrum does not solve the problems of development; it makes them painfully visible, and provides a framework for people to explore ways to resolve problems in short cycles and with small improvement experiments.

Suppose the team fails to deliver what they committed to in the first Sprint due to poor task analysis and estimation skill. To the team, this feels like failure. But in reality, this experience is the necessary first step toward becoming more realistic and thoughtful about their commitments. This pattern – of Scrum helping make visible dysfunction, enabling the team to do something about it – is the basic mechanism that produces the most significant benefits that teams using Scrum experience.

Now, when you know exactly how Scrum works, read more about reasons as to why you should adopt this agile methodology in your product development process. If you are not familiar with Scrum theory, please learn what Scrum actually is and more about its components.

Source:
“Jeff Sutherland’s Scrum Handbook”, Jeff Sutherland, Scrum Training Institute, 2010