The Scrum Framework

There has been a considerable amount of literature dedicated to Scrum. I will provide a clear explanation of the Scrum Framework.

In this blog, I have created a quick read about Scrum and its components — Scrum Values, Events, Roles, Artifacts and Rules that bind these components. I will write different blogs to unleash each component/element in Scrum.

The Scrum Guide is the official description of Scrum written by Ken Schwaber and Jeff Sutherland and is freely available for everyone. (https://scrumguides.org/scrum-guide.html)

Definition of Scrum -

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat

Scrum is —

• Lightweight
• Simple to understand
• Difficult to master

Let us discuss more on the above definition.

Scrum is a Framework -

The dictionary meaning of the word framework means an essential supporting structure of a system, building or object. Similar is the Scrum framework, an important supporting structure for a high-performing team-building complex product.

Scrum can be compared to a chess game: easy to understand and challenging to master and implement. It has elementary components, but when it comes to implementing them, there are hundreds of strategies one can follow, and a strategy that works for one might only work for some.

One has to inspect and adapt the strategies regularly.

The Scrum Framework consists of

1. Three roles — Scrum Master, Product Owner, and the Development Team.
2. Five formal Events — Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and Sprint itself.
3. Three Artifacts — Product Backlog, Sprint Backlog, and Done Increment.
4. Scrum Values — Focus, Openness, Respect, Courage, and Commitment.
5. Rules that bind the above components together.

Adaptive Complex Problem -

According to Stacey Complex Model, any project or Product can be classified into four categories based on three factors (People, Requirements, and Technology) -

1. Simple
2. Complicated
3. Complex
4. Chaos

The diagram below represents the same: the x-axis represents the unknown regarding technology, the y-axis represents the novel regarding requirements, and the z-axis represents the unknown regarding people during product development.

Stacey Complexity Model

The Simple category is where everything is known; a predictive model (waterfall or plan-drive) can work in this category.

Examples -

• Rewriting the Database scripts in a new language or technology.
• Before constructing a house, it is essential to create a plan and then execute it accordingly.

The Complicated category is the one where more is known than the unknowns. A Kanban approach works best in this category.

Example — Automobile manufacturing and assembling.

In the Chaos category, everything is unknown; the sense and act model works best. A frequent plan is created, implemented, inspected, and adapted to a new project.

Example -

Startups in their early stages, who are addressing real-time problems, often find themselves in this category. They must regularly evaluate and adjust their products based on customer feedback.

Software development lies in the Complex category, where more is unknown than known. An empirical approach or empiricism works best in this category.

What makes software development complex?

• Requirements keep changing because of market change, new opportunities, and competition; sometimes, customers must figure out what they want.
• Technology change — New requirements demand technology upgrades.
• People — Many factors are involved here, like people leaving/joining the Product, leaves, skill gaps, etc.

Empiricism -

Scrum is based on the empirical process or empiricism, which means working in a fact-based, event-based, experience-based and evidence-based manner.

Scrum promotes an incremental and iterative approach to optimize predictability and risk.

Three pillars of Scrum are -

1. Transparency
2. Inspection
3. Adaptation

Transparency means presenting the facts as is. Everyone involved in product development trusts each other and is transparent in their daily work. They dare to show both the good and bad news by giving honestly.

Inspection in Scrum includes inspecting the Product, process, and people for their betterment. A skilled inspector effectively does assessment, and feedback is shared.

Adaptation means adapting the facts and feedback from inspection. When an inspector determines that a process or product deviates from accepting limits. An adjustment is made to minimize further deviation. The result of adaptation is continuous improvement.

Every event in Scrum provides a moment to inspect and adapt like

• In Sprint Planning, the Scrum team reviews the product backlog and the action items from the sprint retrospective and inspects the sprint backlog.
• In the Sprint Review, the Scrum team inspects the Product (feedback from the customer or stakeholder) and adapts the product backlog.
• In the Sprint Retrospective, the Scrum team inspects the process and people and adapts at least one item in the product backlog.
• In Daily Scrum, the development team inspects the sprint goal and adapts the daily plan. In Sprint Planning, the scrum team reviews the product backlog and adapts the sprint backlog.

Scrum Values -

A Scrum team can bring empiricism to life and build a culture of trust only when they have scum values embodied and lived by the Scrum team.

There are five Scrum Values —

1. Focus
2. Respect
3. Openness
4. Courage
5. Commitment

All Scrum values complement each other, and all are equally important.

Focus —

Timeboxing every event and delivering value frequently and incrementally brings focus to the team. The incremental approach focuses on what matters the most now rather than what might be necessary.

Openness —

Organization and stakeholders are open and transparent to each other. One should be available to express their viewpoint in all situations. This brings transparency and trust.

Respect —

Scrum teams respect each other's thoughts, experiences, and opinions (every opinion allows you to learn). They appreciate the differences, diversity, Scrum Roles, Agile principles and Rules.

Courage -

The Scrum Team members dare to do the right things. They dare to show the facts as is and be transparent in all good and bad situations.

Commitment is towards

• the team,
• delivering the Product with quality,
• self-learning,
• Sprint Goal,
• excellence,
• agile principles,
• Self-Organizing,
• Definition of done,
• Scrum Framework,
• giving once best to achieve the Goal,
• delivering value.

Scrum Roles -

Scrum prescribes three roles, and each part has its responsibilities.

1. Product Owner
2. Scrum Master
3. Development Team

Scrum Team consists of three roles — Scrum Master, Product Owner, and Development.

The development team serves the Product Owner.

The Product Owner serves the stakeholders.

Scrum Master serves the development team, product owner, development team, and organization.

Product Owner -

The Product Owner in Scrum is the "value" maximizer and optimizer.

The Product Owner works with the development team to deliver value to the customer.

The Product Owner orders the backlog such that the most valuable functionality is delivered first, and only he has the final say on ordering the product backlog.

The Product Owner crafts a product vision and prepares the roadmap that keeps the team focused on delivering value.

One Product has only one product backlog and only one Product Owner. This brings clarity, focus and quick decision-making. One Product backlog also ensures that it is the only source of truth.

The Product Owner takes input from market research, competitive analysis, stakeholder feedback, and customers to order the backlog.

The Product Owner focuses on the "why" part, not the "how" part. They focus on the outcome of the feature delivered and let the development team take care of the implementation.

The Product Owner is also responsible for making the P.B.I.s (Product Backlog Items) clear by writing the description, acceptance criteria, and other details required so that everyone in the team has a clear and exact understanding.

Scrum Master -

I have written another article on "Effective Scrum Master". Please go through that to understand the role of a Scrum Master.

Development Team -

The Development team is a self-organizing and cross-functional team responsible for delivering a done product increment in every Sprint.

Self-Organizing teams mean they manage their work on their own within boundaries. No one, not even Scrum Master or Product Owner, tells them how to deliver work.

A cross-Function team means they have all the skills required to deliver a potentially releasable done increment.

Development Team owns the sprint backlog and is responsible for tracking work progress within a sprint.

They are also responsible for the quality of the Product that adheres to the definition of done.

The recommended size of a Development team per Scrum Guide is three to nine, including Product Owner and Scrum Master. Less than three members in a group may need more skills to deliver done increment every Sprint, and more than nine members team will not be able to self-organize.

Scrum Events -

Scrum prescribes five events, allowing us to inspect and adapt the Product, process, and people.

1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective
5. Sprint

Sprint Planning -

Sprint Planning timeboxed for eight hours for a month's Sprint is an event for Scrum Team to plan for a sprint — what and how to complete the work. Time duration is usually shorter for a shorter sprint.

A Sprint Goal is crafted, which directs the team on what to complete. Based on the sprint goal, the team selects the P.B.I. from the product backlog and creates an actionable plan: the Sprint Backlog.

Scrum Master facilitates sprint planning, but team members can do that.

Product Owner comes with their wish list of P.B.I.s, an ordered list to achieve a business requirement.

Based on the capacity, the Development Team forecasts what they can achieve, keeping Sprint Goal in mind. To calculate the power of the team, team members look at the past delivery and performance of previous sprints, the definition of done and the availability of the team members in the current Sprint.

The Product Owner clarifies any question regarding P.B.I.s and makes a trade-off between technical feasibility and business requirement.

Scrum Team can also invite technical and business experts outside the team for guidance and other inputs.

Daily Scrum -

Daily Scrum timeboxed for fifteen mins is an event for the development team to inspect Sprint Goal and progress towards it. They plan for twenty-four hours and ensure that everyone in the group is aligned towards the progress of the Sprint Goal.

The team also discusses the impediments and tracks their resolution.

The outcome of Daily Scrum can be one of the following -

• An updated Sprint Goal
• An updated Sprint Backlog
• A list of open items

One of the ways of doing the Daily Scrum meeting is by answering three questions -

1. What did I do yesterday to achieve Sprint Goal?
2. What will I work on today to achieve Sprint Goal?
3. Any Impediments that can impact the progress towards Sprint Goal?

Any required technical discussion should be done with the required members outside this event. Remember that Daily Scrum is a status meeting.

All the members of the development team must attend Daily Scrum. This ensures that everyone in the group is updated with the Sprint's progress towards the sprint goal, and they take complete ownership of the sprint backlog. This also helps the team to self-organize.

Scrum Master is not required to attend the Daily Scrum but ensure that it happens daily at the same time and place (this reduces confusion).

It is recommended that a Scrum Master should attend the daily Scrum if the team is new to Scrum.

Product Owners can attend the daily Scrum silently but should refrain from participating as it's an event for the development team. The Product Owner can speak at the request of the Development Team.

Sprint Review -

Sprint Review timeboxed for four hours for a one-month sprint is an event to inspect the product increment and collect the feedback of stakeholders and customers. Based on the feedback and the insights gained product backlog is adapted.

The Product Owner owns this event and is responsible for inviting the stakeholders and customers to the Sprint Review.

The Product Owner presents the Sprint Goal and what the team has accomplished in the form of Product Increment.

Sprint Retrospective -

It is an event where the Scrum team (Development team, Scrum Master and Product Owner) come together and inspect all aspects of work — people, process, technology, tools, product quality, and definition of done.

Sprint Retrospective occurs after the Sprint Review and is timeboxed to three hours for one month sprint. For shorter sprints, it can be shorter.

The team celebrate success and discusses the feedback.

One way of doing this retrospectively is by answering three-question — What went well? What did not go well? What can be improved? The improvement plan is created.

At least one action item goes to the sprint backlog of the next Sprint.

Action items from the last concluded Sprint are discussed whether those are successfully implemented in the Sprint.

Sprint -

Sprint timeboxed for less than a month is like a container for all other events. During a Sprint, a usable, potentially releasable increment is created.

At the end of every Sprint, the team must deliver at least one potentially releasable functionality.

The next Sprint starts immediately after the timebox for the previous Sprint expires.

The Scrum Team crafts a sprint goal during the sprint planning, and no changes are done during the Sprint that endangers the sprint goal.

Only the Product Owner can cancel or terminates a sprint only when the sprint goal becomes obsolete.

Product Backlog Refinement —

Product Backlog refinement is not a formal event in Scrum but is a recommended activity. The development refines the P.B.I.s, which they will work on in the upcoming or sometime within the same Sprint.

The Product Owner provides insights into the P.B.I.s and explains the "why" of the P.B.I.s. They order the backlog and put the most essential item on the top. The development team then refines the P.B.I.s such that they know enough to work on it.

Any dependency on the other team or member is raised.

If any question is raised, the Product Owner answers that question.

The development team also estimates the P.B.I.s and helps the Product Owner to understand the reason behind the estimation.

The Scrum Guide prescribes that Refinement activity should be at most 10% of the team's capacity.

Scrum Artifacts -

There are three artefacts in Scrum -

1. Product Backlog
2. Sprint Backlog
3. Product Increment

Product Backlog -

Product Backlog is an ordered list of all things that need to be done in a product.

One Product has only one Product Owner and one Product Backlog; that is the only source of truth.

It is an ever-evolving artefact that grows and changes more is learned about the Product, its customer and the environment.

Team members can add the items to the product backlog, but the Product Owner is accountable.

Sprint Backlog -

Sprint Backlog is a set of P.B.I.s selected from the Product Backlog for a sprint to complete a Sprint Goal. Sprint Backlog is owned and maintained by the development team. This Sprint Backlog is created during sprint planning.

Sprint Backlog emerges during the Sprint. New things can be added when the team thinks they have the capacity left to complete more work.

Product Increment -

The outcome of a Sprint is a potentially releasable Product Increment that is in the Done state. Done means one which adheres to the definition of done.

Only the Product Owner can decide when to release the product increment to production.

Definition Of Done -

People and Organizations who start implementing Scrum most of the time ask below questions -

When can we call a product backlog item done?

How can we maintain the quality of the Product?

Is there a common understanding among the team members when to call a work done?

The answer to all these questions is a D.O.D. (Definition of Done) which is shared with and transparent to everyone involved in the product development.

The development team creates the definition of done and is also owned by them. They can take input from the Product Owner and the organization's expectations.

It is generally a list of items a P.B.I. must go through before calling it 'Done'.

Example of a D.O.D. -

1. Unit testing of all the logic layers must be above 90%
2. All the mentioned acceptance criteria must pass.
3. The peers must do a code review.
4. All functional test cases must pass

and so on.

All functional and non-functional requirements can be included in the Definition of Done.

The D.O.D. brings the development to a common understanding of when we can call a P.B.I. done and ready to release.

Scrum Team inspects the D.O.D. in every Sprint Retrospective and updates it regularly, raising the bar of the quality standards.

The definition of done also guides the development team in better forecasting as with D.O.D.; team members know what all work needs to be done along with acceptance criteria.

Thanks for reading it out; this was a quick introduction to Scrum. I will be writing more and more regarding Scrum and Agile.