Scrum is an iterative and
incremental Agile software development framework for managing
software projects and product or application development. Its focus is on
"a flexible, holistic product development
strategy where a development team works as a unit to reach a common goal"
as opposed to a "traditional, sequential approach". Scrum enables the
creation of self-organizing teams by encouraging co-location of all team
members, and verbal communication among all team members and disciplines in the
project.
A key principle of Scrum is its recognition
that during a project the customers can change their minds about what they want
and need (often called requirements churn), and that unpredicted challenges
cannot be easily addressed in a traditional predictive or planned manner. As
such, Scrum adopts an empirical approach—accepting that the
problem cannot be fully understood or defined, focusing instead on maximizing
the team's ability to deliver quickly and respond to emerging requirements.
Contents
·
2 Roles
·
3 Sprint
·
4 Events
Scrum was first defined as "a flexible,
holistic product development strategy where a development team works as a unit
to reach a common goal" as opposed to a "traditional, sequential
approach" in 1986 by Hirotaka Takeuchi andIkujiro Nonaka in the "New New
Product Development Game".[1] Takeuchi and Nonaka later
argued in "The Knowledge Creating Company"[2] that it is a form of
"organizational knowledge creation, [...] especially good at bringing
about innovation continuously, incrementally and spirally".
The authors described a new approach to
commercial product development that would increase speed
and flexibility, based on case studies from manufacturing firms in the
automotive, photocopier and printer industries.[3] They called this the holistic or rugby approach, as the whole process is
performed by one cross-functional team across multiple overlapping phases,
where the team "tries to go the distance as a unit, passing the ball back
and forth".[3]
In the early 1990s, Ken Schwaber used what would become
Scrum at his company, Advanced Development Methods, and Jeff Sutherland,
with John Scumniotales and Jeff McKenna, developed a similar approach at Easel
Corporation, and were the first to refer to it using the single word Scrum.[4] In 1995, Sutherland and
Schwaber jointly presented a paper describing the Scrum methodology at the Business Object
Design and Implementation Workshop held as part ofObject-Oriented Programming, Systems, Languages &
Applications '95 (OOPSLA '95) in Austin,
Texas, its first public presentation.[5] Schwaber and Sutherland
collaborated during the following years to merge the above writings, their
experiences, and industry best practices into what is now known as Scrum.
In 2001, Schwaber worked with Mike Beedle to
describe the method in the book Agile Software Development
with Scrum.[6] Its approach to planning
and managing projects is to bring decision-making authority to the level of
operation properties and certainties.[7] Although the word is not an acronym, some
companies implementing the process have been known to spell it with capital
letters as SCRUM. This may be due to one of Ken Schwaber's early papers, which
capitalized SCRUM in the title.[7]
Later, Schwaber with others founded the Scrum
Alliance and created the Certified Scrum Master programs and its derivatives.
Ken left the Scrum Alliance in the fall of 2009, and founded Scrum.org to
further improve the quality and effectiveness of Scrum.
There are three core roles[8] and a range of ancillary
roles. Core roles are often referred to as pigs and ancillary roles as chickens (after the story The Chicken and the Pig).
The core roles are those committed to the
project in the Scrum process—they are the ones producing the product (objective
of the project). They represent the scrum team. Although other roles may
be encountered in real projects, Scrum does not define any roles other than
those described below.[9]
The Product Owner represents the stakeholders
and is the voice of the customer. He is accountable for ensuring
that the team delivers value to the business. The Product Owner writes (or has
the team write) customer-centric items (typically user stories), ranks
and prioritizes them, and adds them to the product backlog.
Scrum teams should have one Product Owner, and while they may also be a member
of the development team, this role should not be combined with that of the
Scrum Master. In an enterprise environment, though, the Product Owner is often
combined with the role of Project Manager as they have the best visibility
regarding the scope of work (products).[citation needed]
The Development Team is responsible for
delivering potentially shippable increments (PSIs) of product at the end of
each Sprint (the Sprint Goal). A Team is made up of 3–9 individuals with
cross-functional skills who do the actual work (analyse, design, develop, test,
technical communication, document, etc.). The Development Team in Scrum is
self-organizing, even though there may be some level of interface with project
management offices (PMOs).
Scrum is facilitated by a Scrum Master, who
is accountable for removing impediments to the ability of the team to deliver
the product goals and deliverables. The Scrum Master is not a traditional team lead or project manager, but
acts as a buffer between the team and any distracting influences. The Scrum
Master ensures that the Scrum process is used as intended. The Scrum Master is
the enforcer of the rules of Scrum, often chairs key meetings, and challenges
the team to improve. The role has also been referred to as a servant-leader to reinforce these dual
perspectives.
The Scrum Master differs from a project
manager in that the latter may have people management responsibilities unrelated
to the role of Scrum Master. The Scrum Master role excludes any such additional
people responsibilities. In fact, there is no role of project manager in Scrum
at all, because none is needed. The traditional responsibilities of a project
manager have been divided up and reassigned among the three Scrum roles, and
mostly to the Development Team and the Product Owner, rather than to the Scrum
Master. Practicing Scrum with the addition of a project manager indicates a
fundamental misunderstanding of Scrum, and typically results in conflicting
responsibilities, unclear authority, and sub-optimal results.[10]
The Scrum process
A sprint (or iteration) is the basic unit of
development in Scrum. The sprint is a "timeboxed"
effort; that is, it is restricted to a specific duration.[11] The duration is fixed in
advance for each sprint and is normally between one week and one month,
although two weeks is typical.[7]
Each sprint is started by a planning meeting,
where the tasks for the sprint are identified and an estimated commitment for
the sprint goal is made, and ended by a sprint review-and-retrospective
meeting,[4] where the progress is
reviewed and lessons for the next sprint are identified.
Scrum emphasizes working product at the end
of the Sprint that is really "done"; in the case of software, this
means a system that is integrated, fully tested, end-user documented, and
potentially shippable.[10]
At the beginning of the sprint cycle (every
7–30 days), a "Sprint planning meeting" is held:[11]
·
Select what work is to be done
·
Prepare the Sprint Backlog that details the time it will
take to do that work, with the entire team
·
Identify and communicate how much of the work is likely
to be done during the current sprint
·
(1st four hours) Entire team: dialog for prioritizing the
Product Backlog
·
(2nd four hours) Development Team: hashing out a plan for
the Sprint, resulting in the Sprint Backlog
A Daily Scrum meeting in
the computing room. This choice of location lets the team start on time.
Each day during the sprint, a project team
communication meeting occurs. This is called a Daily Scrum (meeting) and has specific
guidelines:
·
All members of the development team come prepared with
the updates for the meeting.
·
The meeting starts precisely on time even if some
development team members are missing.
·
The meeting should happen at the same location and same
time every day.
·
The meeting length is set (timeboxed) to 15
minutes.
·
All are welcome, but normally only the core roles speak.
During the meeting, each team member answers
three questions:
·
What have you done since yesterday?
·
What are you planning to do today?
·
Any impediments/stumbling blocks? Any
impediment/stumbling block identified in this meeting is documented by the
Scrum Master and worked towards resolution outside of this meeting. No detailed
discussions shall happen in this meeting.
At the end of a sprint cycle, two meetings
are held: the "Sprint Review Meeting" and the "Sprint
Retrospective".
At the Sprint Review Meeting:
·
Review the work that was completed and the planned work
that was not completed
·
Present the completed work to the stakeholders (a.k.a.
"the demo")
·
Incomplete work cannot be demonstrated
·
Four-hour time limit
At the Sprint Retrospective:
·
All team members reflect on the past sprint
·
Make continuous process improvements
·
Two main questions are asked in the sprint retrospective:
What went well during the sprint? What could be improved in the next sprint?
·
Three-hour time limit
·
This meeting is facilitated by the Scrum Master
Backlog refinement is the ongoing process of
reviewing product backlog items and checking that they are appropriately
prioritised and prepared in a way that makes them clear and executable for
teams once they enter sprints via the sprint planning activity. Product backlog
items may be broken into multiple smaller ones, acceptance criteria may be
clarified, or new preparatory work such as clarification on client needs or
technical spikes may be identified.
Backlog refinement is not a core Scrum
practice but has been adopted as a way of managing the quality of backlog items
entering a sprint.[12]
The Scrum of Scrums (meeting) is a technique
to scale Scrum up to large development groups (over a dozen people), which
allows clusters of teams to discuss their work, focusing especially on areas of
overlap and integration. Each daily scrum within a sub-team ends by designating
one member as an "ambassador" to participate in a daily meeting with
ambassadors from other teams, called the Scrum of Scrums. Depending on the
context, ambassadors may be technical contributors, or each team’s Scrum Master.[13]
The agenda will be like a Daily Scrum, with
the following four questions:[citation needed]
·
What has your team done since we last met?
·
What will your team do before we meet again?
·
Is anything slowing your team down or getting in their
way?
·
Are you about to put something in another team's way?
Resolution of impediments is expected to
focus on the challenges of coordination between the teams, and may entail
agreeing to interfaces between teams, negotiating responsibility boundaries,
etc. The Scrum of Scrums will track these working items via a backlog of its
own, where each item contributes to improving between-team coordination.[13]
Since I originally defined
the Scrum of Scrums (Ken Schwaber was at IDX working with me), I can
definitively say the Scrum of Scrums is not a "meta Scrum." The Scrum
of Scrums as I have used it is responsible for delivering the working software
of all teams to the Definition of Done at the end of the Sprint, or for
releases during the sprint. PatientKeeper delivered to production four times
per Sprint. Ancestry.com delivers to production 220 times per two week sprint.
Hubspot delivers live software 100-300 times a day. The Scrum of Scrums Master
is held accountable for making this work. So the Scrum of Scrums is an
operational delivery mechanism.
 |
This
section needs additional citations for verification. Please
help improve this article by adding
citations to reliable sources. Unsourced material may be
challenged and removed. (March 2013)
|
The product backlog is an ordered list of requirements that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to
be done in order to successfully deliver a viable product. Theproduct
backlog items (PBIs) are ordered by the Product Owner based
on considerations like risk, business value, dependencies, date needed, etc.
The items added to the backlog are commonly
written in story format. The product backlog is What will be delivered, ordered
into the sequence in which it should be delivered. It is open and editable by
anyone, but the Product Owner is ultimately responsible for ordering the items
on the backlog for the Development Team to choose.
The product backlog contains the Product
Owner's assessment of business value and the Development Team's assessment of
development effort, which are often, but not always, stated in story points using a rounded Fibonaccisequence. These
estimates help the Product Owner to gauge the timeline and may influence
ordering of backlog items; for example, if the "add spellcheck" and
"add table support" features have the same business value, the
Product Owner may schedule earlier delivery of the one with the lower
development effort (because the ROI (Return on Investment) is
higher) or the one with higher development effort (because it is more complex
or riskier, and they want to retire that risk earlier).[14]
The product backlog and the business value of
each backlog item is the responsibility of the Product Owner. The size (i.e.
estimated complexity or effort) of each backlog item is, however, determined by
the Development Team, who contributes by sizing items, either in story points
or in estimated hours.
There is a common misunderstanding that only user stories are allowed in a Product
Backlog. By contrast, Scrum is neutral on requirement techniques. As the Scrum
Primer[10] states,
Product Backlog items are
articulated in any way that is clear and sustainable. Contrary to popular
misunderstanding, the Product Backlog does not contain "user
stories"; it simply contains items. Those items can be expressed as user
stories, use cases, or any
other requirements approach that the group finds useful. But whatever the
approach, most items should focus on delivering value to customers.
A Scrum task board
The sprint backlog is the list of work the
Development Team must address during the next sprint. The list is derived by
selecting product backlog items from the top of the product backlog until the
Development Team feels it has enough work to fill the sprint. This is done by
the Development Team asking "Can we also do this?" and adding product
backlog items to the sprint backlog. The Development Team should keep in mind
its past performance assessing its capacity for the new sprint, and use this as
a guide line of how much "effort" they can complete.
The product backlog items are broken down
into tasks by the Development Team. Tasks on the sprint backlog are never
assigned; rather, tasks are signed up for by the team members as needed
according to the set priority and the Development Team member skills. This
promotes self-organization of the Development Team, and developer buy-in.
The sprint backlog is the property of the
Development Team, and all included estimates are provided by the Development
Team. Often an accompanying task board is used to see and change
the state of the tasks of the current sprint, like "to do", "in
progress" and "done".
Once a Sprint Backlog is committed, no
additional functionality can be added to the Sprint backlog except by the team.
Once a Sprint has been delivered, the Product Backlog is analyzed and
reprioritized if necessary, and the next set of functionality is selected for
the next Sprint.
The increment (or potentially shippable
increment,
PSI) is the sum of all the Product Backlog items completed during a sprint and
all previous sprints. At the end of a sprint, the Increment must be done
according to the Scrum Team's criteria called Definition of Done (DoD). The
increment must be in a usable condition regardless of whether the Product Owner
decides to actually release it.
A sample burn down chart
for a completed iteration, showing remaining effort and tasks for each of the
21 work days of the 1-month iteration
The sprint burndown chart is a publicly
displayed chart showing remaining work in the sprint backlog. Updated every
day, it gives a simple view of the sprint progress. It also provides quick
visualizations for reference.
There are also other types of burndown, for
example the release burndown chart that shows the amount of
work left to complete the target commitment for a Product Release (normally
spanning through multiple iterations) and the alternative release
burndown chart,[15] which basically does the
same, but clearly shows scope changes to Release Content, by resetting the
baseline.
The following terms are often used in a Scrum
process.
Scrum Team
Product Owner, Scrum Master and Development
Team
Product Owner
The person responsible for maintaining the
Product Backlog by representing the interests of the stakeholders, and ensuring
the value of the work the Development Team does.
Scrum Master
The person responsible for the Scrum process,
making sure it is used correctly and maximizing its benefits.
Development Team
A cross-functional group of people
responsible for delivering potentially shippable increments of Product at the
end of every Sprint.
Sprint burn down chart
Daily progress for a Sprint over the sprint's
length.
Release burn down chart
Sprint level progress of completed product
backlog items in the Product Backlog.
Product backlog (PBL)
A prioritized list of high-level
requirements.
Sprint backlog (SBL)
A prioritized list of tasks to be completed
during the sprint.
Sprint
A time period (typically 1–4 weeks) in which
development occurs on a set of backlog items that the team has committed to.
Also commonly referred to as a Time-box or iteration.
Spike
A time boxed period used to research a
concept and/or create a simple prototype. Spikes can either be planned to take
place in between sprints or, for larger teams, a spike might be accepted as one
of many sprint delivery objectives. Spikes are often introduced before the
delivery of large or complex product backlog items in order to secure budget,
expand knowledge, and/or produce a proof of concept. The duration and
objective(s) of a spike will be agreed between the Product Owner and Delivery
Team before the start. Unlike sprint commitments, spikes may or may not deliver
tangible, shippable, valuable functionality. For example, the objective of a
spike might be to successfully reach a decision on a course of action. The
spike is over when the time is up, not necessarily when the objective has been
delivered.
Tracer Bullet
The tracer bullet is a spike with the current
architecture, current technology set, current set of best practices which
results in production quality code. It might just be a very narrow implementation
of the functionality but is not throw away code. It is of production quality
and the rest of the iterations can build on this code. The name has military
origins as ammunition that makes the path of the
weapon visible, allowing for corrections. Often these implementations are a
'quick shot' through all layers of an application, such as connecting a single
form's input field to the back-end, to prove the layers will connect as
expected.[citation needed]
Tasks
Work items added to the sprint backlog at the
beginning of a sprint and broken down into hours. Each task should not exceed
12 hours (or two days), but it's common for teams to insist that a task take no
more than a day to finish.[citation needed]
Definition of Done (DoD)
The exit-criteria to determine whether a
product backlog item is complete. In many cases the DoD requires that all regression
tests should be successful.
Velocity
The total effort a team is capable of in a
sprint. The number is derived by evaluating the work (typically in user story points) completed from the
last sprint's backlog items. The collection of historical velocity data is a
guideline for assisting the team in understanding how much work they can do in
a future sprint.
Impediment
Anything that prevents a team member from
performing work as efficiently as possible.[16]
Sashimi
A report that something is "done".
The definition of "done" may vary from one Scrum team to another, but
must be consistent within one team.
Abnormal Termination
The Product Owner can cancel a Sprint if
necessary.[9] The Product Owner may do so
with input from the team, Scrum Master or management. For instance, management
may wish to cancel a sprint if external circumstances negate the value of the
sprint goal. If a sprint is abnormally terminated, the next step is to conduct
a new Sprint planning meeting, where the reason for the termination is
reviewed.
ScrumBut
No comments:
Post a Comment