What is Scrum ?

Scrum is an Agile framework that was initially developed for software development projects, but its usefulness extends to other complex and innovative tasks. In fact, Scrum can also be applied to marketing, particularly in the context of agile marketing. The Good Agency is a marketing company that understands the benefits of using Scrum in project management.

In agile marketing, Scrum enables teams to manage projects effectively, prioritize tasks, and enhance collaboration among team members. By breaking down large projects into smaller, more manageable tasks and completing them within time-boxed iterations (sprints), agile marketing teams can deliver high-quality results more efficiently.

Moreover, the iterative nature of Scrum allows marketing teams to adapt and continuously improve their campaigns. By regularly reviewing progress and adjusting plans as needed, teams can respond quickly to changing market conditions and customer needs, thereby improving the effectiveness of their marketing campaigns.

Why is it called Scrum ?

When Jeff Sutherland created the scrum process in 1993, he borrowed the term “scrum” from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by Rugby teams. Scrum is the leading agile development methodology, used by Fortune 500 companies around the world. The Scrum Alliance exists to transform the way we tackle complex projects, bringing the Scrum framework and agile principles beyond software development to the broader world of work.

Why is Scrum Popular ?

At its core Scrum is based on an iterative feedback loop and time-boxed sprints (periods of planning & value creation). Software development is very complex, it is extremely hard if not impossible to know how an ideal solution to a problem would look like upfront. On top of that what’s “ideal” tends to change over time.

Therefore choosing an iterative approach to developing software to leverage information and insight gained on the fly is very pragmatic. It is also used in other disciplines with similar constraints (highly competitive, changing environment) like military reconnaissance. On top of that most of the software that is written today is never ‘finished’. This is especially true for successful software. It is rather improved and maintained for extended periods of time (think decades).

Scrum is a better fit for the way we think of software today than other (more sequential) methodologies that came before Scrum.

What Scrum is not ?

Scrum is not…

• a term interchangeable with the term “Agile”. Agile is defined by it’s creators as a philosophy and is fundamentally four values and twelve principles. Scrum, if implemented correctly, adheres to the values and principles found in the Agile Manifesto. Scrum should “be” Agile.
• a philosophy. A philosophy is a set of values or concepts. Scrum is a targetable framework. Teams treating the implementation of Scrum like a philosophy misunderstand the framework aspect and details for Scrum. To move from confusing Scrum with being a philosophy to Scrum as a framework, they should be implementing Scrum based on the published Scrum Guide.
• a methodology. Scrum, as a framework, sets up a set of events, roles, and artifacts. Each of those items has a set of specific expectations, inputs and outputs relative to both time and order. How you perform to achieve those expectations exactly, is where the flexibility comes into play.
• a team thing. It is an organization transformation. I have refereed to the team quite a bit, but in reality, for a Scrum Team to be successful, they cannot be dropped into an organization that is not committed to the values and principles of Agile. Said another way, Agility requires that organizations treat teams differently to help them achieve the benefits of agility.

Scrum Theory

Scrum

• Founded on empiricism
• Comprised of
  • Scrum Teams
  • Roles
  • Rules
  • Events
  • Artifacts
• Pillars that uphold Scrum
  • Transparency
  • Inspection
  • Adaption
• Opportunities to Inspect and Adapt
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
• Burn-down Charts show how much work remains till the end of the Sprint.
• Cone of Uncertainty shows how much is known about the Product over time
• Each component within the Scrum framework serves a specific purpose and is essential to Scrum’s success and usage.
• Scrum is not a process or a technique for building products. It is a framework within which you can employ various processes and techniques. It does not describe agile processes and techniques.
• If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
• If an organization has decided to adopt Scrum but management wants to change the terminology
  • Management may feel less anxious, however
  • Without a new vocabulary as a reminder of the change, very little change may actually happen, and
  • The organization may not understand what has changed with Scrum and the benefits of Scrum may be lost

Sprint

• The length of a Sprint should be
  • No more than one month
  • Short enough to keep the business risk acceptable by the Product Owner
  • Short enough to be able to synchronize the development work with other business events
• Scrum does not require having aligned Sprints for multiple teams.
• If the Development Team is not able to finish the complete forecast, the Product Owner and Development Team should review and adjust the Sprint work selected
• Can be cancelled by only the Product Owner
  • Any completed and Product Backlog Items are reviewed
  • If part of the work is releasable the Product Owner accepts it
  • Incomplete Product Backlog Items are re-estimated and put back on the Product Backlog
  • The Sprint is cancelled only if the Sprint Goal becomes obsolete
• 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 between the Product Owner and Development Team as more is learned
• During the first Sprint, the Development Team
  • Delivers an increment of releasable software
  • Develops and delivers at least one piece of functionality
• Development Teams deliver an Increment of Product functionality every Sprint
  • This Increment is usable so a Product Owner may choose to immediately release it
  • Each Increment only contains “Done” functionality that could be released immediately
  • It is not mandatory that the Increment be released to production at the end of each Sprint
  • It is not normal to have a “hardening” Sprint to remove technical debt and prepare the Product for upcoming release
• The Sprint is over when the time-box expires.
• The next Sprint begins immediately after the conclusion of the previous Sprint.

Sprint Goal

• Provides guidance to the Development Team on why it is building the Increment.
• The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.
• After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.
• If the Sprint Goal becomes obsolete the Sprint may be cancelled.

Scrum Artifacts

Scrum users must frequently inspect Scrum Artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

Sprint Backlog

• The Product Backlog items selected for this Sprint plus the plan for delivering them.
• Created at the Sprint Planning.
• Belongs solely to the Development Team
  • Development Team members are never exclusive owners of a Sprint Backlog Item
  • All Sprint Backlog Items are owned by the entire Development Team, even though each one may be done by an individual Development Team member
• The Development Team modifies the Sprint Backlog throughout the Sprint
  • The Development Team may learn more about the work needed to achieve the Sprint Goal
  • As new work is required the Development Team adds it to the Sprint Backlog
  • Only the Development Team may change the Sprint Backlog
• If an item in the Sprint Backlog cannot be finished by the end of the Sprint it should be renegotiated between the Product Owner and Development Team.
  • The Sprint is not cancelled in this case

Product Backlog

• Is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product
  • Product Backlog Items are ordered with most valuable and clear items at the top
• Used to describe the upcoming work on the product
  • All Development Teams working together on the same product should be using the same Product Backlog
• Is managed by the Product Owner
  • The Product Owner is the sole person responsible for the Product Backlog
  • The Product Owner can delegate some work related to Product Backlog management to the Development Team
  • The Product Owner is responsible for the content, availability and ordering of the Product Backlog
• Product Backlog refinement consumes no more than 10% of the capacity of the Development Team.
• Features of a Product Backlog
  • Never complete
  • Evolves as the product and the environment in which it will be used evolves
  • Dynamic — constantly changes to identify what the product needs to be appropriate, competitive, and useful
  • As long as a product exists, its Product Backlog also exists
• Product Backlog management includes
  • Clearly expressing Product Backlog items
  • Ordering the items in the Product Backlog to best achieve goals and missions
  • Optimizing the value of the work the Development Team performs
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
  • Ensuring the Development Team understands items in the Product Backlog to the level needed

Increment

• The Increment is the sum of all the Product Backlog Items completed during the Sprint and the value of the increments of all previous Sprints.
• Only members of the Development Team create the Increment.

The only Guide to DevOps you will ever need. Right here.

Scrum Roles

Scrum Team

• The Scrum Team consists of
  • A Product Owner
  • The Development Team
  • A Scrum Master
• Scrum Teams are self-organizing
  • Choose how to best accomplish their work rather than being directed by others outside the team
• Scrum Teams are cross-functional
  • Have all competencies needed to accomplish the work without depending on others not part of the team
• There are three main qualities the Scrum Team is designed to optimize
  • Flexibility
  • Creativity
  • Productivity

Product Owner

• Characteristics of the Product Owner
  • Product value maximizer
  • Lead facilitator of Key Stakeholder involvement
  • Product marketplace expert
• Is responsible for managing the Product Backlog
  • Maintains the content, availability and ordering of Product Backlog Items
  • Can delegate some work related to Product Backlog management to the Development Team
  • Most valuable and clear items are placed at the top of the Product Backlog
• Is responsible for the monitoring of the remaining work towards the Project Goal
  • Tracks total work remaining at least every Sprint Review
  • Compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal
  • This information is made transparent to all stakeholders.
• Has the authority to cancel the Sprint
  • Only the Product Owner has this authority
• May be part of the Development Team if they are also executing the work of the Sprint Backlog.
• There is only one Product Owner in a Scrum Team
  • The Product Owner is one person
  • They may represent the interests of a committee

Development Team

• The optimal Development Team size is between 3 and 9 people.
• Product Owner and Scrum Master may be part of the Development Team if they are also executing the work of the Sprint Backlog.
• Responsible for all estimates in the Product Backlog.
  • The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
• Creates the Increment.
• By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
• Responsible for tracking the total work remaining in the Sprint Backlog and the likelihood of achieving the Sprint Goal
  • This responsibility is solely the Development Team’s and not the Product Owner’s or Scrum Master’s
• Allowed to change the Sprint Backlog during the Sprint
  • Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
• Can be allowed to make changes to the Product Backlog if delegated by the Product Owner
• Development Teams have the following characteristics
  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment
  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole
• During the first Sprint, the Development Team
  • Delivers an increment of releasable software
  • Develops and delivers at least one piece of functionality

Scrum Master

• Serves the Development Team by
  • Helping the Development Team to create high-value products
  • Coaching the Development Team in self-organization and cross-functionality
  • Removing impediments to the Development Team’s progress
  • Facilitating Development Team decisions
• May be part of the Development Team if they are also executing the work of the Sprint Backlog.
• Serves the organization by
  • Planning Scrum implementations within the organization
  • Leading and coaching the organization in its Scrum adoption
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
• Does the following regarding the Daily Scrum
  • Ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum
  • Teaches the Development Team to keep the Daily Scrum within the 15 minute time-box
  • Enforces the rule that only Development Team members participate in the Daily Scrum
• Is a servant-leader for the Scrum Team
  • Helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t
  • Helps everyone change these interactions to maximize the value created by the Scrum Team
• Responsible for coping with incomplete artifact transparency.
• Serves the Product Owner in several ways
  • Finding techniques for effective Product Backlog management
  • Helping the Scrum Team understand the need for clear and concise Product Backlog Items
  • Understanding product planning in an empirical environment
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
  • Understanding and practicing agility
  • Facilitating Scrum Events as requested or needed

Non-Scrum Roles

• Only two meetings in which people outside the Scrum Team are allowed to participate
  • Sprint Planning
    • The Development Team may invite other people to attend the Sprint Planning in order to provide technical or domain advice.
  • Sprint Review
    • The Product Owner is responsible for inviting the Key Stakeholders to the Sprint Review meeting

Key Stakeholders

• Allowed to participate in the Sprint Review meeting
  • Not allowed to participate in any other Scrum Events

Scrum Events

Sprint Planning

• Time-boxed to a maximum of 8 hours for 1 month Sprints
  • For shorter Sprints the event is usually shorter
• Attended by the entire Scrum Team
  • Product Owner, Development Team and Scrum Master all attend
  • Other people may be invited to attend in order to provide technical or domain advice
• Answers
  • How will the work needed to deliver the Increment be achieved?
  • What can be delivered in the Increment resulting from the upcoming Sprint?
• Does not answer
  • Who will be responsible for each item in the Sprint Backlog?
  • What new technologies could be used to speed up the Development Team velocity?
  • What is the size of the Technical Debt and how it could be removed?
• Inputs to the Sprint Planning are
  • The Product Backlog
  • The latest product Increment
  • Projected capacity of the Development Team during the Sprint
  • Past performance of the Development Team
• Only work planned for the first days of the Sprint is required to be decomposed to units of one day or less.
  • The Development Team should be able to explain to the Product Owner and Scrum Master how it indends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment

Learn how to make beautiful dashboards. Get the complete e-Guide here.

Daily Scrum

• Time-boxed to 15 minutes
  • No matter the size of the Development Team
• Only the Development Team can participate
  • Other people could attend but cannot participate
• Cannot be skipped
• Opportunity for the Development Team to synchronize activities and create a plan for the next 24 hours
• Three main questions each member of the Development Team should answer
  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Sprint Review

• Time-boxed to a 4 hour meeting for 1 month Sprints
  • For shorter Sprints the event is usually shorter
• Attended by
  • The Scrum Team
    • The Product Owner
    • The Development Team
    • The Scrum Master
  • Key Stakeholders
• The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

Sprint Retrospective

• Time-boxed to a 3 hour meeting for 1 month Sprints
  • For shorter Sprints the event is usually shorter
• 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.
• 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
  • Create a plan for implementing improvements to the way the Scrum Team does its work
• During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.

Definition of “Done”

• The Development Team is responsible for the creation of the Definition of “Done”
  • If the Definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
  • If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Teams must define a Definition of “Done” appropriate for the product.
  • If there are multiple Scrum Teams working on the system or product release, the Development Teams on all of the Scrum Teams must mutually define the Definition of “Done””
• Helps the Scrum Team
  • Definition of “Done” is used to assess when work is complete on the product Increment
  • Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
  • Definition of “Done” ensures artifact transparency
• Accounts for
  • Conventions, standards and guidelines of the Organization
  • Definition of “Done” of other Scrum Teams working on the same Product
• Does not account for
  • Definition of “Done” of other Scrum Teams working on other products
  • Experience of the Product Owner
  • Advice of the Scrum Master
• During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.