By María del Carmen Jiménez Lázaro
Why Scrum is one of the most popular agile frameworks? To answer that question, I’ll mention the main advantages of Scrum:
- Works well for fast-moving development projects.
- Helps teams release products quickly and efficiently.
- Short sprints enable changes in early phases of the development based on the feedback.
- Higher quality and productivity.
- Increases customer/user satisfaction.
Of course, Scrum has also some disadvantages… Nothing is perfect! But knowing them, you can solve these drawbacks. There are a couple of handicaps that I would like to highlight:
- It’s challenging for large teams.
- As Scrum says, it is simple to understand and difficult to master. When it is not applied properly, dysfunctions or anti-patterns may appear.
Scrum is the most popular software framework for development projects. It was initially designed to release products efficiently though it can double the production of anything, no matter whether it’s sales, finance, marketing, and so on. Scrum simple encourages teams to work better and with higher quality.
Now let’s get to the point. What’s Scrum? As Scrum.org, the Home of Scrum, says:
“Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.”
Scrum is a framework that allows collaborative work between teams. Helps them organize, iterate and continuously improve the delivery of products or services on which they are working. Always focusing on the client’s needs, always shipping value to customers. Thus reduces risks and costs.
Scrum is based on the empirical model and, with regards to people, it promotes the self-organization of teams to deal with the unpredictable and solve complex problems by continually inspecting and adapting.
Before I start talking about the framework itself, I would like to mention that Scrum is a set of explicit and transparent values and principles that amplify the power of Scrum. They usually come with a culture change, they change the way you think and work creating a great work environment.
The illustration above contains the 5 values: Courage, Focus, Commitment, Respect and Openness. When all those five values are lived by the Scrum Teams, the pillars of transparency, inspection, and adaptation also come to life and trust appears at all levels.
As you may have noticed, Scrum.org frequently reviews and adapts itself. In 2020 there have been several changes introduced in Scrum Guide. To enable self-organization, empiricism, and focus, Scrum no longer emphasizes roles but instead accountabilities: Scrum Master, Product Owner and Developers. The three of them form the Scrum Team.
The Scrum Team is a small group of people, typically 10 or fewer people, accountable for delivering value in every Sprint. In that way, communication is better and people are more productive. They are cross-functional, they have all the skills necessary to deliver value, and self-managing, they are the ones who decide about how to do their work.
The Scrum Master is accountable for enacting Scrum in the Scrum Teams and the organization, helping others to understand Scrum. The Scrum Master is accountable for coaching in self-management and cross-functionality, removing the impediments that interfere in the work of the team and coaching the Product Owner in managing the Product Backlog.
The Product Owner is accountable for maximizing the value and the success of the product in the market. He/she is accountable for crafting the vision of the product, a brief statement of the future state of the product or service according to the market and user needs, and managing the stakeholders and the Product Backlog. The Product Owner is responsible for communicating the vision to the stakeholders, users, customers, and, of course, the Scrum Teams working on the product.
The Developers are accountable for turning the Product Backlog into Increments of potentially releasable usable functionality every Sprint with the quality the market demands. They have to avoid silos and use the continuous delivery or DevOps practices. To sum up, look for technical excellence. Scrum recognizes no titles nor sub-teams within the team and promotes self-organization, they are the only ones who choose how to best accomplish their work.
The Scrum Process
Please have a look at the following illustration that summarizes Scrum as Ken Schwaber and Jeff Sutherland represent it in Scrum.org. In there you can observe the different events and artifacts of the framework within the main container event that is the Sprint:
The process begins when the Product Owner creates the Product Vision at where the team should head. The vision is broken down into User Stories, which are the requirements that make up the Product Backlog. The Product Backlog is divided into the Sprint Backlog at the beginning of the Sprint to define the work to be done by the developers, more precisely at the Sprint Planning. At this point begins the development of the product Increment or new functionality that will be reviewed in the Sprint Review by the interested stakeholders to receive feedback. On each day of the Sprint, the Developers hold the Daily Scrum in which they adjust their plan to meet the Sprint Goal. The Sprint closes with Retrospective to carry out the inspection and adaptation that Scrum requires. Then, another fast cycle begins.
Each of the Scrum events is specifically designed to enable the transparency and inspection required in the agile methodologies. They are used to create regularity and to minimize the need for meetings not defined in Scrum. All the events are time-boxed, there is a maximum limit.
- Sprint: It is the heart of Scrum, the container of the other events. It is time-boxed between one week and one month.
- Sprint Planning: Initiates the Sprint by laying out the work to be performed in the Sprint. Sets the transformation of the “What?” (vision/goal of the Product Owner) into the “How?” (work of the Developers). It is time-boxed to 8 hours for a one-month Sprint and the entire Scrum Team has to attend.
- Daily Scrum: Allows the Developers to inspect progress toward the Sprint Goal and how progress is trending toward completing the work. The Sprint Backlog can be adapted as necessary. It is time-boxed to 15 minutes per day at the same time and place each day to reduce complexity.
- Sprint Review: The goal of the event is to inspect the outcome of the Sprint and determine future adaptations discussing the progress toward the Product Goal with the stakeholders. It is then more than a demo, it is another opportunity to inspect and adapt. It is time-boxed to 4 hours in one-month Sprints and all the Scrum Team has to attend. The Product Owner is responsible for inviting the stakeholders.
- Sprint Retrospective: The whole team reviews the finished Sprint and plans how to increase quality and effectiveness, what went wrong and well not only regarding people but also to processes. The team aims to identify possible process improvements and generate a plan to implement them as soon as possible. It is time-boxed to 3 hours for a one-month Sprint and all the Scrum Team has to attend.
The Scrum Artifacts provide the key information so that the Scrum Team and the stakeholders have a common understanding of the product being developed, its value and the activities to carry it out. They are designed to enhance inspection and adaptation.
There are three main artifacts, each of which contains a commitment to provide transparency and focus:
- Product Backlog: It is a single and prioritized list of all the things required to build the product. It is dynamic, never complete, and evolves with the product and its environment.
Its commitment is the Product Goal, which describes the long-term objective or future state of the product. Used by the Scrum Team to plan against and maintain focus.
- Sprint Backlog: It is a set of the Product Backlog Items (PBIs), with no external dependencies, selected for the Sprint plus a plan for delivering the product Increment and reaching the Sprint Goal. The Developers forecast what functionality will be in the next “Done” Increment.
Its commitment is the Sprint Goal, a single objective that provides coherence and focus to the team. During the Sprint, the Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog without affecting the Sprint Goal.
- Increment: It is the sum of all the “done” items of the Product Backlog completed in the Sprint plus the items of the previous Sprints. The Increment always has to meet the Definition of Done and be usable regardless of whether the Product Owner releases it or not.
Its commitment is the Definition of Done, a list of activities common to every user story to assess whether they are finished. It is an agreement defined by the organization or the Scrum Team that allows meeting the quality required for the product.
There are other artifacts not mentioned in the Scrum Guide such as the Burndown Chart and the Definition of Ready that can be helpful for the team.
- Burndown Chart: It is a graph that gives the team an overview of the remaining work in the Sprint. It guides the team to the successful completion of the Sprint when it is updated every day.
- Definition of Ready: It is a checklist used to evaluate if the PBI’s are ready for the Sprint. In the new Scrum Guide 2020, the alternative to this is the Product Backlog Refinement that is the act of adding detail, such as a description, size, and order to the PBI’s. The refinement is an ongoing process, there is no time-box limit.