Agile and Scrum methodology & Framework software development Complete Tutorial
1. Scrum - Overview
Agile has become one of the big buzzwords in the software development industry. But what
exactly is agile development? Put simply, agile development is a different way of executing
software development teams and projects.
To understand what is new, let us recap the traditional methods. In conventional software
development, the product requirements are finalized before proceeding with the development.
Agile has become one of the big buzzwords in the software development industry. But what
exactly is agile development? Put simply, agile development is a different way of executing
software development teams and projects.
To understand what is new, let us recap the traditional methods. In conventional software
development, the product requirements are finalized before proceeding with the development.
2. Agile Development
Agile development is based on iterative incremental development, in which requirements and
solutions evolve through team collaboration. It recommends a time-boxed iterative approach, and
encourages rapid and flexible response to change. It is a theoretical framework and does not
specify any particular practice that a development team should follow. Scrum is a specific agile
process framework that defines the practices required to be followed.
Agile Manifesto
The Agile Manifesto is as follows:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
Key Principles of Agile
The Agile Manifesto is based on the following principles:
The Agile Manifesto is based on the following principles:
Principle
|
Description
|
Satisfaction and Delivery
|
Customer satisfaction through early and continuous working
software. |
Welcoming Change
|
Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
|
Deliver Frequently
|
Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
|
Communication is the
Key |
Business people and developers must work together daily
throughout the project.
|
Environment and Trust
|
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
|
Face-to-face
Communication |
The most efficient and effective method of conveying information
to and within a development team is face-to-face conversation.
|
Software as Measure of
Progress |
Working software is the primary measure of progress.
|
Attention to Details
|
Continuous attention to technical excellence and good design
enhances agility.
|
The Power of Less
|
Simplicity—the art of maximizing the amount of work not being
done—is essential.
|
Self-organizing Teams
|
The best architectures, requirements and designs emerge from
self-organizing teams.
|
3. Agile Methodologies
Scrum
It is the most popular agile framework, which concentrates particularly on how to manage tasks
within a team-based development environment. Scrum uses iterative and incremental
development model, with shorter duration of iterations. Scrum is relatively simple to implement
and focuses on quick and frequent deliveries.
It is the most popular agile framework, which concentrates particularly on how to manage tasks
within a team-based development environment. Scrum uses iterative and incremental
development model, with shorter duration of iterations. Scrum is relatively simple to implement
and focuses on quick and frequent deliveries.
4. Scrum - Framework
Scrum is a framework for developing and sustaining complex products. Ken Schwaber and Jeff
Sutherland developed Scrum. Together, they stand behind the Scrum Rules.
Scrum is a framework for developing and sustaining complex products. Ken Schwaber and Jeff
Sutherland developed Scrum. Together, they stand behind the Scrum Rules.
Scrum Definition
Scrum is a framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.
Scrum is a process framework that has been used to manage complex product development since
the early 1990s. Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and development practices so that you can
improve.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and
rules. Each component within the framework serves a specific purpose and is essential to
Scrum’s success and usage.
Scrum is a framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.
Scrum is a process framework that has been used to manage complex product development since
the early 1990s. Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and development practices so that you can
improve.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and
rules. Each component within the framework serves a specific purpose and is essential to
Scrum’s success and usage.
Scrum Process Framework
In Scrum, the prescribed events are used to create regularity. All events are time-boxed events,
such that every event has a maximum duration. The events are described more elaborately in the
subsequent chapters.
In Scrum, the prescribed events are used to create regularity. All events are time-boxed events,
such that every event has a maximum duration. The events are described more elaborately in the
subsequent chapters.
Sprint
The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a potentially
releasable product increment is created. A new Sprint starts immediately after the conclusion of
the previous Sprint. Sprints consist of the Sprint planning, daily scrums, the development work,
the Sprint review, and the Sprint retrospective.
• In Sprint planning, the work to be performed in the Sprint is planned collaboratively by
the Scrum Team.
• The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to
synchronize the activities and create a plan for that day.
• A Sprint Review is held at the end of the Sprint to inspect the Increment and make
changes to the Product Backlog, if needed.
• The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint
Planning. In this meeting, the Scrum Team is to inspect itself and create a plan for
improvements to be enacted during the subsequent Sprint.
The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a potentially
releasable product increment is created. A new Sprint starts immediately after the conclusion of
the previous Sprint. Sprints consist of the Sprint planning, daily scrums, the development work,
the Sprint review, and the Sprint retrospective.
• In Sprint planning, the work to be performed in the Sprint is planned collaboratively by
the Scrum Team.
• The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to
synchronize the activities and create a plan for that day.
• A Sprint Review is held at the end of the Sprint to inspect the Increment and make
changes to the Product Backlog, if needed.
• The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint
Planning. In this meeting, the Scrum Team is to inspect itself and create a plan for
improvements to be enacted during the subsequent Sprint.
5. Scrum - Roles
The Scrum Team consists of three roles, namely a ScrumMaster, a Product Owner, and the
Team.
The Scrum Team consists of three roles, namely a ScrumMaster, a Product Owner, and the
Team.
ScrumMaster
The ScrumMaster (sometimes written as the Scrum Master, although the official term has no
space after “Scrum”) 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 ScrumMaster (sometimes written as the Scrum Master, although the official term has no
space after “Scrum”) 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.
Some people in the industry refer to this team as development team. However, such a reference
is leading to controversy that the team can have only developers and no other roles. It is an
obvious understanding that it is only a misconception. To develop a software product, we require
all the roles and that is the essence of scrum – the team will function in collaboration. Crossfunctional 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.
6. Scrum - ScrumMaster
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.
Some people in the industry refer to this team as development team. However, such a reference
is leading to controversy that the team can have only developers and no other roles. It is an
obvious understanding that it is only a misconception. To develop a software product, we require
all the roles and that is the essence of scrum – the team will function in collaboration. Crossfunctional 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.
6. Scrum - ScrumMaster
ScrumMaster is a trained responsible person, who renders services
as described below -
ScrumMaster Services to the Product Owner
TheScrumMaster serves the Product Owner in several ways, including -
• 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 that the Product Owner knows how to arrange the Product Backlog to maximize
value.
• Understanding and practicing agility.
• Facilitating Scrum events as needed.
TheScrumMaster serves the Product Owner in several ways, including -
• 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 that the Product Owner knows how to arrange the Product Backlog to maximize
value.
• Understanding and practicing agility.
• Facilitating Scrum events as needed.
ScrumMaster Services to the Scrum Team
The ScrumMaster serves the Scrum Team in several ways, including -
• Coaching the Scrum Team in self-organization and cross-functionality.
• Helping the Scrum Team to create high-value products.
• Removing impediments to the Scrum Team’s progress.
• Facilitating Scrum events as requested or needed.
• Coaching the Scrum Team in organizational environments in which Scrum is not yet
fully adopted and understood.
The ScrumMaster serves the Scrum Team in several ways, including -
• Coaching the Scrum Team in self-organization and cross-functionality.
• Helping the Scrum Team to create high-value products.
• Removing impediments to the Scrum Team’s progress.
• Facilitating Scrum events as requested or needed.
• Coaching the Scrum Team in organizational environments in which Scrum is not yet
fully adopted and understood.
ScrumMaster Services to the Organization
TheScrumMaster serves the organization in several ways, including-
• Leading and coaching the organization in its Scrum adoption.
• Planning Scrum implementations within the organization.
• Helping employees and stakeholders understand and enact Scrum and empirical product
development.
• Causing change that increases the productivity of the Scrum Team.
• Working with other ScrumMasters to increase the effectiveness of the application of
Scrum in the organization.
7. Scrum - Events
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
TheScrumMaster serves the organization in several ways, including-
• Leading and coaching the organization in its Scrum adoption.
• Planning Scrum implementations within the organization.
• Helping employees and stakeholders understand and enact Scrum and empirical product
development.
• Causing change that increases the productivity of the Scrum Team.
• Working with other ScrumMasters to increase the effectiveness of the application of
Scrum in the organization.
7. Scrum - Events
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.
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.
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.
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.
Ahmed Yasir Khan Page 13 of 27
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.
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.
Ahmed Yasir Khan Page 13 of 27
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.
Reference
Scrum Guide © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved.
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.
Reference
Scrum Guide © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved.
8. 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.
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.
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.
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.
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.
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.
9. Scrum - Questions
Following are some FAQs regarding Scrum -
Question: What is the difference between Scrum and Agile Development?
Answer : Agile Development is a software methodology, whereas Scrum is one of process
frameworks that follows Agile.
Question: Are Sprints and Iterations the same?
Answer : Both Sprints of Scrum and Iterations of Iterative Incremental model deliver working
product increments. Followings are the difference in these:
• Lifecycles of Sprint and Iteration are different.
• Sprints are time-boxed, while Iterations are not.
• Duration of Sprints is much less compared to durations of Iterations.
Question: Is Scrum Master a job title or a role that someone with an existing job title fills?
Answer : Scrum Master is a role that someone with a job title fills. Normal practice is that the
person playing the role of project manager plays the ScrumMaster’s role as well.
Question: Can Product Owner and ScrumMaster’s roles be played by the same person?
Answer : No, since the ownership differs. Product Owner takes care of the Product Backlog,
Prioritization of User Stories, and Validation of the working product increment with the user
stories allocated to the Sprint.
Question: Is it that Scrum Projects need not have any Documentation?
Answer : No. Scrum Projects, like any other Projects require documentation such as user stories,
design, test cases, etc.
Following are some FAQs regarding Scrum -
Question: What is the difference between Scrum and Agile Development?
Answer : Agile Development is a software methodology, whereas Scrum is one of process
frameworks that follows Agile.
Question: Are Sprints and Iterations the same?
Answer : Both Sprints of Scrum and Iterations of Iterative Incremental model deliver working
product increments. Followings are the difference in these:
• Lifecycles of Sprint and Iteration are different.
• Sprints are time-boxed, while Iterations are not.
• Duration of Sprints is much less compared to durations of Iterations.
Question: Is Scrum Master a job title or a role that someone with an existing job title fills?
Answer : Scrum Master is a role that someone with a job title fills. Normal practice is that the
person playing the role of project manager plays the ScrumMaster’s role as well.
Question: Can Product Owner and ScrumMaster’s roles be played by the same person?
Answer : No, since the ownership differs. Product Owner takes care of the Product Backlog,
Prioritization of User Stories, and Validation of the working product increment with the user
stories allocated to the Sprint.
Question: Is it that Scrum Projects need not have any Documentation?
Answer : No. Scrum Projects, like any other Projects require documentation such as user stories,
design, test cases, etc.
