Scrum Framework Theory

• Scrum is a framework for developing complex products. It's not a technique or a definitive method.
• Scrum addresses complex adaptive problems , while productively and creatively delivering products of the highest possible value.
• Scrum is lightweight, simple to understand but difficult to master.
• The Scrum framework consists of Scrum Teams (small team of people) and their associated roles , events , artifacts , and rules.
• Scrum is used in very diverse areas, from developing software and hardware to managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.
• Scrum is founded on empirical process control theory, or empiricism.
  • Empiricism asserts that knowledge comes from experience.
• Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation (TIA).
  • Transparency – Significant aspects of the process must be visible to those responsible for the outcome. Observers need have a common understanding of what is being seen.
  • Inspection – Scrum users must regularly inspect Scrum artifacts (product backlog, sprint backlog, the increment) and progress toward a Sprint Goal to detect undesirable results
  • Adaptation – As soon as a deviation from the expect result is determined, an adjustment must be made as soon as possible. Scrum prescribes four formal events for inspection and adaptation : Spring Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
• The Scrum Values are: commitment, courage, focus, openness and respect (CCFOR). These values are important to bring to life the three pillars of Scrum and build trust to everyone.
  • Commitment – Everyone personally commit to achieve the goals of the team.
  • Courage – Everyone have courage to do the right thing and work on tough problems.
  • Focus – Everyone focuses on the work of the Sprint and the goals of the team.
  • Openness – The team and the stakeholders agree to be open about all the work and the challenges to perform it.
  • Respect – Everyone respect each other to be capable, independent people.

The Scrum Team

• Consists on a Product Owner, the Development Team, and a Scrum Master.
• Scrum Teams are:
  • Self-organizing – Choose how best to accomplish their work.
  • Cross-functional – Everyone has all competencies needed to accomplish the work without depending on others that are not part of the team.
• The team model is designed to optimize flexibility , creativity , and productivity.
• There is no Project Manager role in Scrum and in general, the Product Owner role is by no means to be confused with a Project Manager. The responsibilities of a Project Manager are distributed between the Product Owner, the Scrum Master and the rest of the team.

Product Owner

• The main responsibility is to maximize the value (this value could come in various forms) of the product resulting from work of the Development Team.
• Is only one person, not a committee. But can represent the desires of a committee.
• Is the sole person responsible for managing the Product Backlog :
  • The items on the Product Backlog should be clearly expressed and understood by the Development Team.
  • Is responsible for ordering the items in the Product Backlog.
  • Ensure that the Product Backlog is visible, transparent, and clear.
  • The Product Backlog should show what the Scrum Team will work next.
• The Product Owner may do the above work or have the Development Team do it. However, the Product Owner still remains accountable.

Development Team

• Their goal is to deliver a potentially releasable Increment of "Done" product at the end of each Sprint.
• Only the Development Team can create the Increment.
• The Development Team is structured and empowered by the organization to organize and manage their own work.
• The teams are self-organizing. Only they made the decisions in how the Product Backlog should be turned into potentially shippable Increments. The benefits are commitment , accountability and creativity. Also optimizes flexibility.
• They are cross-functional (the team should have the skills needed to create the Increment). There is no titles in Development Team, even if the work is done for someone. So, the accountability belongs to the Development Team as a whole.
• It is possible for the Product Owner or the Scrum Master to be part of the Development Team, but not recommended.
• The Development Team should have between 3 to 9 team members.

Scrum Master

• The Scrum Master assists the Development Team and the Product Owner and is responsible for promoting and supporting Scrum within the organization. The Scrum Master ensures that everyone understands the Scrum theory, practices, rules and values.
• The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change.
• The Scrum Master is not a manager, but more like a servant leader.
• Scrum Master service to the Product Owner :
  • Understanding Scrum and Agile practices.
  • Ensuring that goals, scope and product domain are understood.
  • Learn effective Product Backlog management.
  • Product planning in an empirical environment.
  • Can facilitate planning and Backlog refinement.
• Scrum Master service to the Development Team :
  • Coaches in self-organization and cross-functionality.
  • Helps to create high-value products.
  • Remove impediments.
  • Facilitating Scrum events (not a secretary).
  • Coaching the Scrum values.
• Scrum Master service to the Organization :
  • Coaches the organization.
  • Works with other Scrum Masters.
  • Cause changes that increase the productivity of the Scrum Team.
  • Coaches Scrum and empirical product development.

Scrum Events

Sprint

• Timebox of one-month or less. Short enough to keep the business risk acceptable to the Product Owner, and able to synchronize the development work with other business events.
• Sprints contain all the prescribed Scrum Events, a flexible plan on how to build a Product Increment and of course the development work needed.
• Each Sprint has the Sprint Goal that helps the Development Team better understand why it is building the Increment.
• During the Sprint:
  • No changes are made that would endanger the Sprint Goal.
  • Quality goals do not decrease.
  • Scope may be clarified and re-negotiated.
• There is no gap between Sprints and nothing happens between Sprints.
• A Sprint can be cancelled (very rare).
  • Only the Product Owner can do it.
  • This can happen if:
  • The Sprint Goal becomes obsolete.
  • Major changes in the market occur.
  • Company decides to change direction.
  • If it's canceled:
  • Completed items will be reviewed.
  • Incomplete items will be re-estimated and put back in the Product Backlog.

Sprint planning

• Time-boxed to a maximum of eight hours for a one-month Sprint.
• Normally happens after the conclusion of the previous Sprint.
• Answers the following:
  • What can be delivered in the Increment resulting from the next Sprint.
  • How will the work needed would be achieved.
• A Spring Goal is defined by the Product Owner and the Development Team. Even if the objective of the Sprint Goal is at first defined by the Product Owner, the number of the Product Backlog items selected is solely up to the Development Team (upon negotiation with the Product Owner). To define this, the following is evaluated:
  • Previous Product Increment
  • Projected capacity of the Development Team.
  • Past performance of the Development Team.
• The Development Team can invite people outside the Scrum Team to provide technical or domain advice.
• This meeting cannot identify all the work that needs to be done in advance. Only a plan with enough detail so that the development work can start. By the end of the meeting, this plan should be decomposed often to units of one day or less. The Development Team should be able to explain their plan to accomplish the Sprint Goal.
• At the end of the meeting, this should be defined:
  • The Spring Goal
  • The Product Backlog items selected and the plan for delivering them (this is the Spring Backlog)

Daily Scrum

• Time-boxed of 15 minutes, every day and at the same time and place.
• Only the Development Team attends this meeting. They could allow others to be present, and the Scrum Master has the role to make sure that the team has the meeting.
• It's a key to inspect and adapt pillars
• The Development Team inspect progress toward completing the work in the Sprint Backlog and reaching the Sprint Goal.
• The interactions that the Development Team has should improve communication, identify impediments and promote quick decision making.
• Examples of questions to be answered:
  • What did I do yesterday?
  • What will I do today?
  • Do I see any impediment?
• If needed, the Development Team can meet immediately after the Daily Scrum to further discuss and decide on how do the rest of the Sprint work will be completed.
• This meeting should result in a common understanding of how the Sprint is progressing and what needs to be done next to meet the Sprint Goal.

Spring review

• Time-boxed to a maximum of four hours for a one-month Sprint.
• Happens at the end of a Sprint to inspect the Increment and adapt the Product Backlog if needed.
• The Product Owner owns this meeting and will invite key Stakeholders to this event. The Development Team and the Scrum Master are also present. The Scrum Master role is to facilitate this meeting and to make sure it is held within the time-box.
• It's an informal meeting.
• The items that have been Done and not Done are explained by the Product Owner.
• The Development Team discusses what went well, what were the problems, and how these problems can be resolved.
• The Development Team demonstrates the work that is been Done
• The Product Owner discusses the Product Backlog and explains when the next release might be available.
• The entire group collaborates on what to do next, discusses changes in the marketplace and what is important to do next.
• This meeting can result in a revised Product Backlog. The items that were not done, are put back in the Product Backlog.

Spring Retrospective

• Time-boxed to a maximum of three hours for a one-month Sprint.
• It's the last event before the end of the Sprint. Happens after the Sprint Review and before the Sprint Planning.
• The goal of the Sprint Retrospective is for the Scrum Team to inspect itself and the process, and create a plan for improvements for the next sprint.
• Only the Scrum Team is present.
• The Scrum Master is a facilitator in this meeting, makes sure that everybody understands the purpose and ensures that the meeting is positive and productive and coaches a team to keep the event within the time-box.
• The objective is to look into how the last Sprint went with regards to people, relationships, processes, and tools.
• Get reflections on what went well and what can be improved.
• Create a plan for implementing those improvements in the next Sprint.
• The Definition of Done could be improved.
• The result of this meeting is the improvements that the Scrum Team will implement in the next Sprint.

Scrum Artifacts

Product Backlog

• An ordered list of everything that is known to be needed in the product.
• Artifact designed to provide transparency and opportunities for inspection and adaptation.
• Single source of all features, functions, requirements, enhancements and fixes for any future changes to be made to the product. As long as the product exists so will its Product Backlog.
• Never complete and constantly changing.
• The Product Owner is the only responsible for the Product Backlog.
• If multiple teams who work on the same Product, only one Product Backlog should be used.
• The Product Backlog items characteristics are description, order, estimate and value. Could also have a test description.
• The Development Team is responsible for the estimates.
• Product Backlog items that are positioned higher in the Product Backlog are more important as they provide much greater value and are usually clearer and more detailed as the items in the lower part of the Product Backlog. The top items are more refined, so they should be small enough to be included in the next Sprint.
• The Product Backlog refinement is the act of adding detail, estimates, and order to items. Time-boxed event that should not occupy more than 10 per cent of the capacity of the Development Team.

Sprint Backlog

• Set of Product Backlog items selected for the Sprint, plus a plan for delivering the Increment and achieve the Sprint Goal.
• The Sprint Backlog should also include at least one important process improvement identified during the last Sprint Retrospective.
• Temporary Artifact that exists only during the Sprint.
• The Development Team is the only responsible for the Sprint Backlog. If new work is required, the Development Team adds it.
• The scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
• As work is performed or completed, the estimated remaining work is updated.
• The Development Team is responsible for monitoring the progress and the likelihood of reaching the Sprint Goal. This should be tracked at least in every Daily Scrum.

Increment

• Is the sum of all Product Backlog Items completed during a Sprint, plus the value of all Increments from all previous Sprints.
• At the end of each Sprint, the Increment must be completed according to the Definition of Done.
• The Product Owner is the responsible for if and when to release the Increment.

Definition of Done

• Every member of the Scrum Team must have a shared understanding of what it means for work to be complete, to ensure transparency.
• The purpose of each Sprint is to deliver increments that respect the current definition of Done.
• Guides the Development Team in knowing how many Product Backlog items it can select for the Sprint Backlog
• Who creates the Definition of Done?
  • The Development Organization - Typically most organizations have already development processes in place, standards that must be followed, procedures and quality standards. If there is no convention by the organization, should be the development team to define it.
  • The Development Team
  • The Development Team of the Scrum Team must define a definition of Done appropriate for the Product if there is none defined by the development organization.
  • The Development Team may involve the Product Owner in this process and may define rules and quality criteria that are stricter but still following the Definition of Done that the organization has.
  • If there are multiple Scrum Teams, all Development Teams should agree on a definition of Done.

Scrum Terms

Burn-down Chart

• A chart which shows the amount of work which is thought to remain a backlog.
• Is only related to the remaining work.
• Isn't related to project costs or business value, nor related to the productivity of the Development Team.

Burn-up Chart

• A chart which shows the amount of work which has been completed.
• Provides a visual representation of a Sprint's completed work related to its total scope, which is represented by the number of selected Product Backlog Items

Cone of uncertainty

• Describes the evolution of the amount of uncertainty during a project.
• As more is learned, uncertainty tends to decrease.

Technical debt

• The typically unpredictable overhead of maintaining the product, ofter caused by less than ideal design decisions. Also known as Design Debt or Code Debt.
• May exist unintentionally in the Increment or introduced purposefully to realize value earlier.
• Technical Debt is something that should be continuously dealt with and not postponed.
• Technical Debt is tightly coupled with the quality of the product.

Velocity

• Is a measure of the amount of work a Development Team can handle during a typical Sprint.
• Is not mandatory in Scrum, and not correlated with value. Only estimates are made, no commitment is done.

Sources:

• Scrum Guide
• Scrum Master Certification Preparation & 240+ Prep Questions, Udemy Course, Valentin Despa
• Scrum Quizzes, Mikhail Lapshin
• Forget Burndown Use Burnup Charts, Lee Richardson