Overview of Scrum

Scrum is a project management framework that is applicable to any project with aggressive
deadlines, complex requirements and a degree of uniqueness. In Scrum, projects move
forward via a series of iterations called sprints. Each sprint is typically two to four weeks
long. Scrum overview will tell us common concepts in Scrum. They are as follows:

Scrum team: A typical scrum team has between five and nine people. This team does not
include any of the traditional software engineering roles such as programmer, designer,
tester or architect. Everyone on the project works together to complete the set of work they
have collectively committed to complete within a sprint. Scrum teams develop a deep form
of camaraderie and a feeling that “we’re all in this together.”

Product owner: The product owner is the project’s key stakeholder and represents users,
customers and others in the process. The product owner is often someone from product
management or marketing, a key stakeholder or a key user.

Scrum Master: The Scrum Master is responsible for making sure the team is as productive
as possible. The Scrum Master does this by helping the team use the Scrum process, by
removing impediments to progress, by protecting the team from outside, and so on.

Product backlog: The product backlog is a prioritized features list containing every desired
feature or change to the product. Note: The term “backlog” is used for two different things.
The product backlog is a list of desired features for the product. The sprint backlog is a list
of tasks to be completed in a sprint.

Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held,
during which the product owner presents the top items on the product backlog to the team.
The Scrum team selects the work they can complete during the coming sprint. That work is
then moved from the product backlog to a sprint backlog, which is the list of tasks needed
to complete the product backlog items the team has committed to complete in the sprint.

Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is
conducted. This meeting helps set the context for each day’s work and helps the team stay
on track. All team members are required to attend the daily scrum.

Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they
accomplished during the sprint. Typically, this takes the form of a demonstration of the new
features, but in an informal way; for example, PowerPoint slides are not allowed. The
meeting must not become a task in itself nor a distraction from the process.

Sprint retrospective: Also at the end of each sprint, the team conducts a sprint
retrospective, which is a meeting during which the team (including its ScrumMaster and
product owner) reflect on how well Scrum is working for them and what changes they may
wish to make for it to work even better.
Each of the Scrum terms has its own page within the Scrum section, so be sure to check out
all the pages in the navigation.

Scrum - Roles
The Scrum Team consists of three roles, namely a ScrumMaster, a Product Owner, and the
Team.

ScrumMaster

The ScrumMaster is the keeper of the scrum process. He/she is responsible for-

 making the process run smoothly

 removing obstacles that impact productivity
 organizing and facilitating the critical meetings

Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of
the Team. How this is done may vary widely across organizations, Scrum Teams, and
individuals.
The Product Owner is the sole person responsible for managing the Product Backlog.
Product Backlog management includes-
 Expressing Product Backlog items clearly.
 Ordering the Product Backlog items to best achieve goals and missions.
 Optimizing the value of the work the Team performs.
 Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows
what the Team will work on further.
 Ensuring that the Team understands items in the Product Backlog to the level
needed.
The Product Owner may do the above work, or have the Team do it. However, the Product
Owner remains accountable for these tasks.
The Product Owner is one person, not a committee. The Product Owner may represent the
desires of a committee in the Product Backlog, but those wanting to change a Product
Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her
decisions. The Product Owner’s decisions are visible in the content and ordering of the
Product Backlog. No one is allowed to tell the Team to work from a different set of
requirements, and the Team is not allowed to act on what anyone else says. This is
ensured by ScrumMaster.
The Team

The Team is self-organizing and cross-functional. That means the team comprises of
analysts, designers, developers, testers, etc. as appropriate and as relevant to the project.
To develop a software product, we require all the roles and that is the essence of scrum –
the team will function in collaboration. Cross-functional teams have all competencies
needed to accomplish the work without depending on others not part of the team, and thus
time and effort can be saved. The team model in Scrum is designed to optimize flexibility,
creativity, and productivity.
Optimal Team size is small enough to remain nimble and large enough to complete
significant work within a Sprint. The Team size should be kept in the range from five to
nine people, if possible. Fewer than five team members decrease interaction and results in
smaller productivity gains. Having more than nine members requires too much
coordination.
The scrum team works together closely, on a daily basis, to ensure the smooth flow of
information and the quick resolution of issues. The scrum team delivers product iteratively
and incrementally, maximizing opportunities for feedback. Incremental deliveries of a
complete product ensure a potentially useful version of working product is always available.

Scrum – Events or Cermonies

Scrum Process Framework can be viewed by means of a sequence of events and the
corresponding artifacts. The Scrum events are time-boxed events. That means, in a
project, every scrum event has a predefined maximum duration. These events enable
transparency on the project progress to all who are involved in the project. The vital events
of scrum are-

 The Sprint
 Sprint Planning
 Daily Scrum Meetings
 The Sprint Review
 The Sprint Retrospective

The Sprint

During a Sprint, a working product Increment is developed. It is usually of duration two

weeks or one month, and this duration remains constant for all the sprints in the project.
We cannot have varying durations for the different sprints in a project. A new Sprint starts
immediately after the conclusion of the previous Sprint.
The Sprint Goal is an objective set for the Sprint. It provides guidance to the Team on why
it is building the Increment. It is created during the Sprint Planning meeting. The scope of
the sprint is clarified and re-negotiated between the Product Owner and the Team as more
about the requirements is learned. Thus, each Sprint is associated with it, a definition of
what is to be built, a design, and the flexible plan that will guide building it, the
development work, and the resultant product increment.
A Sprint should be cancelled if the Sprint Goal becomes obsolete. This might occur if the
organization changes direction or if market or technology conditions change. A sprint can
be cancelled only by product owner, though others have an influence on the same.
Due to the short duration nature of Sprints, cancellation during a sprint rarely makes
sense. As the sprint cancellations consume resources, for getting re-organized into another
Sprint, they are very uncommon.
If a Sprint is cancelled, and part of the work produced during the sprint is potentially
releasable, the Product Owner typically accepts it. All the incomplete Sprint Backlog Items
are put back into the Product Backlog.

Sprint Planning

The work to be performed in the Sprint is planned in the Sprint Planning Meeting. Sprint
Planning Meeting is of duration of maximum of four hours for two weeks sprints and eight
hours for one month Sprints. It is the responsibility of the Scrum Master to ensure that the
meeting takes place and that all the required attendees are present and understand the
purpose of the scheduled meeting. The Scrum Master moderates the meeting to monitor
the sustenance of discussion and closure on time.
Sprint Planning focuses on the following two questions -

 What needs to be and can be delivered in the Sprint Increment?

 How will the work needed for the execution of Sprint be achieved?
The inputs to this meeting are -

 The Product Backlog

 The latest product Increment
 Projected capacity of the Team during the Sprint
 Past performance of the Team
The Scrum Team discusses the functionality that can be developed during the Sprint.
Product Owner provides clarifications on the Product Backlog items. The team selects the
items from the Product Backlog for the Sprint, as they are the best to assess what they can
accomplish in the Sprint. The Team comprises of analysts, designers, developers, and
testers. The work is carried out in a collaborative fashion, thus minimizing re-work.
The Scrum Team then comes up with Sprint Goal. The Sprint Goal is an objective that
provides guidance to the Team on why it is building the Product Increment. The Team then
decides how it will build the selected functionality into a working product Increment during
the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering
them is called the Sprint Backlog.
Work during a sprint is estimated during sprint planning and may be of varying size and/or
effort. By the end of the Sprint Planning meeting, the work is divided into tasks of duration
of one day or less. This is to enable the ease of work allocation, and tracking the
completion. If the Team realizes that it has too much or too little work, it can renegotiate
the selected Product Backlog items with the Product Owner.
The Team may also invite others (not part of Scrum Team) to attend the Sprint Planning
meeting to obtain technical or domain advice or help in estimation.

Daily Scrum Meetings

The Daily Scrum Meeting is a 15-minute meeting for the Team, conducted daily to quickly
understand the work since the last Daily Scrum Meeting and create a plan for the next 24
hours. This meeting is also referred to as Daily Stand up Meeting.
The Daily Scrum Meeting is held at the same time and same place every day to reduce
complexity.
During the meeting, each Team member explains -
 What did he do yesterday that helped the Team meet the Sprint Goal?
 What will he do today to help the Team meet the Sprint Goal?
 Does he see any impediments that prevent him or the Team from meeting the
Sprint Goal?
Daily Scrum is mistaken to be a status tracking event, though, in fact, it is a planning
event.
The input to the meeting should be how the team is doing toward meeting the Sprint Goal,
and the output should be a new or revised plan that optimizes the team’s efforts in
meeting the Sprint Goal.
Though the Scrum Master coordinates the Daily Scrum Meeting and ensures that the
objectives of the meeting are met, the Meeting is the responsibility of the Team.
If necessary, the Team may meet immediately after the Daily Scrum Meeting, for any
detailed discussions, or to re-plan the rest of the Sprint’s work.
Following are the benefits of Daily Scrum Meetings -
 Improve communication within the Team.
 Identify impediments, if any, in order to facilitate an early removal of the same, so
as to minimize impact on the Sprint.
 Highlight and promote quick decision-making.
 Improve the Team’s level of knowledge.

Sprint Review

A Sprint Review is held at the end of every Sprint. During the Sprint Review, a presentation
of the increment that is getting released is reviewed. In this meeting, the Scrum Team and
the stakeholders collaborate to understand what was done in the Sprint. Based on that,
and any changes to the Product Backlog during the Sprint, the attendees arrive at the next
steps required that could optimize value. Thus, the objective of Sprint Review is to obtain
feedback and progress unitedly.
The Sprint Review is normally held for two hours for two week sprints and for four hours
for one month sprints.
The Scrum Master ensures that -
 The meeting takes place.
 The participants understand the purpose.
 The meeting is focused on the required agenda and is completed within the required
duration.
The Sprint Review includes the following aspects -
 Attendees include the Scrum Team and key stakeholders, as invited by the Product
Owner.
 The Product Owner explains what Product Backlog items have been completed
during the sprint and what has not been completed.
 The Team discusses what went well during the Sprint, what problems it ran into, and
how those problems were solved.
 The Team demonstrates the work that it has completed and answers questions, if
any, about the Increment.
 The entire group then discusses on what to do next. Thus, the Sprint Review
provides valuable input to Sprint Planning of the subsequent Sprint.
 The Scrum Team then reviews the timeline, budget, potential capabilities, and
marketplace for the next anticipated release of the product increment.
 The outcome of the Sprint Review is an updated Product Backlog, which defines the
probable Product Backlog items for the next Sprint.

Sprint Retrospective

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint
Planning. This is usually a one hour meeting for two-week duration sprints and a three
hour meeting for one month duration Sprints.
The purpose of the Sprint Retrospective is to -
 Combine the learnings from the last Sprint, with regards to people, relationships,
process, and tools.
 Identify the major items that went well and potential improvements.
 Creation of a plan for implementing improvements to increase product quality.
The Sprint Retrospective is an opportunity for the Scrum Team to introspect and improve
within the Scrum process framework so as to make the next Sprint outcome more
effective.

Scrum - Artifacts
Scrum Artifacts provide key information that the Scrum Team and the stakeholders need to
be aware of for understanding the product under development, the activities done, and the
activities being planned in the project. The following artifacts are defined in Scrum Process
Framework -

 Product Backlog
 Sprint Backlog
 Burn-Down Chart
 Increment
These are the minimum required artifacts in a scrum project and project artifacts are not
limited by these.
Product Backlog

The Product Backlog is an ordered list of features that are needed as part of the end
product and it is the single source of requirements for any changes to be made to the
product.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases. Product Backlog
items have the attributes of a description, order, estimate, and value. These items are
normally termed as User Stories. The Product Owner is responsible for the Product Backlog,
including its content, availability, and ordering.
A Product Backlog is an evolving artifact. The earliest version of it may contain only the
initially known and best understood requirements. The Product Backlog gets developed as
the product, and the environment in which it will be used, progress. The Product Backlog
constantly changes to incorporate what is required to make it effective. As long as a
product exists, its Product Backlog also exists.
As the product being built is used and gains value, the Product Backlog becomes a larger
and more exhaustive list. Changes in business requirements, market conditions, or
technology, cause changes in the Product Backlog, making it a live artifact.
Product Backlog refinement means adding detail, estimates, and priority order to the
Product Backlog items. This is an ongoing process performed by the Product Owner and the
Team. The Scrum Team decides how and when refinement is to be done.
Product Backlog items can be updated at any time by the Product Owner or at the Product
Owner’s discretion.
Higher-ordered Product Backlog items are usually clearer and more detailed than lower-
ordered ones. More precise estimates are made based on the greater clarity and increased
detail. The lower the order, the lesser is the detail.
Product Backlog items that may likely be the candidate requirements for the upcoming
Sprint are refined so that these items can be developed during the Sprint. Product Backlog
items that can be developed by the Team within one Sprint are deemed to be ready for
selection in a Sprint planning meeting.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan
for delivering the product Increment and realizing the Sprint Goal.
The Sprint Backlog is a forecast by the Team about what functionality will be made
available in the next Increment and the work needed to deliver that functionality as a
working product Increment.
The Sprint Backlog is a plan with enough detail that can be understood but the Team to
track in the Daily Scrum. The Team modifies the Sprint Backlog throughout the Sprint, and
the Sprint Backlog emerges during the Sprint. This emergence occurs as the Team works
through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Team adds it to the Sprint Backlog. As work is performed or
completed, the estimated remaining work is updated. When elements of the plan are
deemed unnecessary, they are removed. Only the Team can change its Sprint Backlog
during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the
Team plans to accomplish during the Sprint, and it belongs solely to the Team.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint
combined with the increments of all previous Sprints. At the end of a Sprint, the new
Increment must be a working product, which means it must be in a useable condition. It
must be in working condition regardless of whether the Product Owner decides to actually
release it.
The Scrum Team needs to have consensus on what is considered to be an Increment. This
varies significantly per Scrum Team, but, team members must have a shared
understanding of what it means for work to be complete. This is used to assess when work
is complete on the product Increment.
The same understanding guides the Team in knowing how many Product Backlog items it
can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of
potentially releasable functionality.
Teams deliver an Increment of product functionality every Sprint. This Increment is
useable, so a Product Owner may choose to release it immediately. If the understanding of
an increment is part of the conventions, standards, or guidelines of the development
organization, all Scrum Teams must follow it as a minimum. If it is not a convention of the
development organization, the Scrum Team must define a definition of Increment
appropriate for the product.
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all
Increments work together.
As Scrum Teams mature, it is expected that their definitions of Increments expands to
include more stringent criteria for higher quality. Any one product should have a definition
of Increment that is a standard for any work done on it.

Sprint Burn-Down Chart

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be
summed. The Team tracks this total work remaining for every Daily Scrum to project the
likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Team can manage its progress.
Sprint Burn-Down Chart is a practice for trending the work expended by the Scrum Team.
This has been proven to be a useful technique in monitoring the Sprint progress towards
the Sprint Goal.
The Product Owner tracks this total work remaining at least every Sprint Review. The
Product Owner compares this amount with work remaining at previous Sprint Reviews to
assess progress toward completing the projected work by the desired time for the goal.
This information is shared with all stakeholders.

Conclusion

Scrum’s roles, events, artifacts, and rules are inevitable. If only some parts of Scrum are
implemented, the result is not Scrum. Scrum needs to be implemented in its entirety and
functions well if aligned with other techniques, methodologies, and practices.
Differences between Extreme Programming and Scrum

Scrum Extreme Programming (XP)

In Scrum framework, team

work in iterations In Extreme
called Sprint which are 1-2 Programming(XP), teamwork
month long. for 1-2 weeks only.

Scrum model do not allow Extreme Programming allow

changes in their timeline or changes in their set
their guidelines. timelines.

Extreme Programming
Scrum emphasizes self- emphasizes strong
organization. engineering practices

In Scrum framework, team In Extreme Programming,

determines the sequence in team have to follow a strict
which the product will be priority order or pre-
developed. determined priority order.

Scrum framework is not

fully described. If you want
to adopt it then you need Extreme Programming(XP)
to fill the framework with can be directly applied to a
your own frameworks team. Extreme Programming
method like XP, DSDM or is also known for its Ready-
Kanban. to-apply features.