1. Scrum is an agile framework that uses short development iterations called sprints to incrementally deliver working software. 2. Key Scrum roles include the Product Owner who manages priorities and requirements, the Scrum Master who facilitates the process, and the Development Team who does the work. 3. Scrum uses artifacts like the Product Backlog to track requirements, Sprints to structure work into timeboxes, and Daily Scrums for the team to synchronize.

1. SCRUM
BOOST PRODUCTIVITY &
BEAT DEADLINES

2. Why Scrum is Probably the Most E
fficient System Out There
• A lot of organizations in the world operate this
way – they fulfill requirements that people
from the higher ups tell them to meet, start wor
king on a plan that they have discussed,
and then meet up with a client or a boss to
check if they like what they have done.
• Now, you can see that there is a likelihood of f
ailure in this type of management, and that
failure is more likely to be discovered right on t
hat project’s deadline.

3. What is Wrong with the System, A
nyway?
• there is no guarantee that all things that the org
anization has thought of would actually work. From
here, you would realize that the Waterfall Method h
as the following issues:
1. People blindly follow plans.
While planning
is important, it is also important that developers a
nd quality checkers understand how
things should happen, especially with the client or t
he end-user.

4. 2. This method can take up too many resources.
3. End-users do not know what they want.
4. Testing for quality may suffer.

5. Enter Scrum
• Scrum, an Agile method, aims to help
you solve problems in product creatio
n with
extreme flexibility. This framework aims
to make you address adaptive and c
omplex problems with the highest produc
tive value without compromising producti
vity in the process.

6. •Scrum
implements an incremental and iter
ative approach to make sure that
you have a handle over risk and
also optimize predictability of your
tasks.

7. • Scrum framework stands on three pillars:
1. Transparency:
All important steps and aspects of all
processes are visible to those who are
responsible for
outcomes.

8. 2. Inspection
Those who are using Scrum are bound
to always check artifacts and progress
in Sprint
Goals in order to see if there are
any variances that they do not want.

9. 3. Adaptation
If the person that took care of the inspection sees
that there are aspects of the process that
would make the end product unacceptable, then mate
rials and processes are immediately
adjusted to create the desired outcome. These adjust
ments are made as soon as possible in
order to minimize any other resulting deviations.

10. What Makes Scrum Great
1. Customer satisfaction
2. Less resources needed
3. Faster turnaround time
4. Better employee satisfaction

11. Can Scrum Work All the Time?
A framework known as Cynefin (Snowden and
Boone 2007) is a sense-making framework that helps us
understand the situation in which we have to operate
and decide on a situation-appropriate approach.
It defines and compares the characteristics of five
different domains: simple, complicated, chaotic,
complex, and a fifth domain, disorder.

13. Complex Domain
When dealing with complex problems, things are more
unpredictable than they are predictable. If there is a right answer,
we will know it only with hindsight. This is the domain of
emergence. We need to explore to learn about the problem, then
inspect and adapt based on our learning.

14. In this environment high levels of interaction and communication
are essential. Innovative new-product development falls into this
category as does enhancing existing products with innovative new
features.
Scrum is particularly well suited for operating in a complex domain.
In such situations our ability to probe (explore), sense (inspect),
and respond (adapt) is critical.

15. Complicated Domain
Complicated problems are the domain of good practices dominated
by experts. There might be multiple right answers, but expert
diagnosis is required to figure them out.
Although Scrum can certainly work with these problems, it might
not be the best solution.
Much of day-to-day software maintenance (dealing with a flow of
product support or defect issues) falls into this category. This is
also where many of the tactical, quantitative approaches like Six
Sigma are particularly well suited, although these tactical
approaches can also apply with simple domain.

16. Simple Domain
When dealing with simple problems, everyone can see cause and
effect. Often the right answer is obvious and undisputed. This is
the domain of legitimate best practices. There are known
solutions.
Scrum can be used for simple problems, but it may not be the most
efficient tool for this type of problem. Using a process with a well-
defined, repeatable set of steps that are known to solve the
problem would be a better fit. For example, if we want to
reproduce the same product over and over again, a well-defined
assembly-line process would be a better fit than Scrum.

17. Or deploying the same commercial-off-the-shelf (COTS) product into
the 100th customer environment might best be completed by
repeating a well-defined and proven set of steps for installing and
configuring the product.

18. Chaotic Domain
Chaotic problems require a rapid response. We are in a crisis and
need to act immediately to prevent further harm and reestablish
at least some order. For example, suppose a university published
an article stating that our product has a flawed algorithm that is
producing erroneous results. Our customers have made substantial
business investments based on the results from our product, and
they are filing lawsuits against us for large damages.

19. Our lead algorithm designer is on holiday in the jungles of Borneo
and can’t be reached for two more weeks. Scrum is not the best
solution here. We are not interested in prioritizing a backlog of
work and determining what work to perform in the next iteration.
We need the ability to act immediately and decisively to stem the
bleeding. With chaotic problems, someone needs to take charge of
the situation and act.

20. Disorder
You are in the disorder domain when you don’t know which of the
other domains you are in. This is a dangerous place to be because
you don’t know how to make sense of your situation.
Unfortunately, these tend to be a rather poor fit for much of
software development. When you are in the disorder domain, the
way out is to break down the situation into constituent parts and
assign each to one of the other four domains. You are not trying to
apply Scrum in the disorder domain; you are trying to get out of
this domain.

21. Interrupt-Driven Work
Scrum is not well suited to highly interrupt-driven work. Say you run a
customer sup-
port organization and you want to use Scrum to organize and manage your
support
activities. Your product backlog is populated on a continuous basis as you
receive
support requests via phone or email. At no point in time do you have a
product back-
log that extends very far into the future, and the content and order of
your backlog
could change frequently (perhaps hourly or every few minutes).

22. In interrupt-driven environments you would be better off
considering an alternative agile approach called Kanban. Kanban is
not a stand-alone process solution, but instead an approach that is
overlaid on an existing process.

23. SCRUM FRAMEWORK

26. Scrum Roles

27. The Product Owner
He is responsible for telling what should be developed a
nd the order of items that needs to
be fulfilled.
he creates the product backlog that contains all the p
roduct goals that the
development team needs to accomplish when they are r
eady to start working. The product owner also needs to
be available at all times in any case the development
team and the
ScrumMaster has any question about the goals that he
has mentioned in his product backlog.

28. 1. Manage economics
a. economics at release level:
At this point, the product owner makes a series of
trade-offs when it comes to date, scope,
quality, and budget as he gets information during th
e product development.

29. For example, if he sees that the team may produce
a product that may create extra revenue if they
work
on an additional week, then he must make a tra
de-
off for the budget and the product’s final release.
b. economics at sprint-level
c. economics in product backlog
2. Take part in planning

30. 4. Make criteria on what is acceptable and check t
hat people are meeting them.
The acceptance criteria are crucial to the Scrum t
eam because it tells everyone about the
project’s progress.
5. Work with the development team
6. Work with the stakeholders

31. When the product owner is able to work
closely with all persons involved in the product crea
tion that are outside the Scrum team,
he would be able to gather all the input that he
needs to create a coherent vision in the
development process. This way, the entire Scrum tea
m prevents unwanted risks in
developing features that may not meet client and c
ustomer satisfaction.

32. Scrum Master
The Scrum
Master takes care of team guidance in developing
the product, as well as
following the process based on Scrum. He is the
one who makes everyone understand
practices, principles, and values that everybody needs
to stick to in order to achieve the
success of the project.

33. The Scrum
Master also helps resolve potential issues and make
improvements on the
projects by following Scrum. He also makes sure t
hat the team is protected from any
outside interference and removes anything that may
hamper productivity.
However, this does not mean that the Scrum
Master has total control over the team –
he acts as a leader,
and not as a traditional project manager.

34. Because Scrum is designed to prevent variances and
make work in progress more
efficient, the development team would arrive to tha
t point when they do not need coaching anymore.
However, the Scrum
Master would be very valuable whenever the Scrum
team is
about to start a new sprint and the entire team
needs to incorporate a product backlog that
they have not encountered before.

35. Development team
The development team determines methods on deliveri
ng what the product master has
asked for. This team is comprised by different peo
ple with different job descriptions, such
as designer, tester, and database administrator, and
architect, which allows them to cross-
function and become dynamic when it comes to de
signing, testing, and building the
product required by the product owner.

36. Because of their task, it is important that the
development team is capable of being self-
organized to decide on the best way to meet the
goals that are set by the product owner.
Here are the responsibilities that the development team h
as within the Scrum framework
1. Execute the sprint
When a sprint happens, all members of the development
team do the designing,
integrating, building, and testing of all items in the pr
oduct backlog by working in
increments and producing potentially shippable features.

37. 2. Grooming the backlog
Whenever a sprint planning happens or before they
start producing features, the development team allots
its time to assist the product owner when it co
mes to refining, prioritizing items, and creating items
on the product backlog.

38. 3. Planning the sprint :
The development team works with the product owne
r and the Scrum Master to develop the
goals that they need to achieve during the next
sprint. The team would be responsible for
identifying which subset of the product backlog shou
ld be prioritized in order to achieve
the goals they have identified.

39. 4. Inspect and Adapt
When a sprint ends, the development team becomes
involved in reviewing the features they have accompl
ished in the previous sprint and what technical an
d process practices they need to adapt in their ne
xt sprint.

40. Scrum Activities and Artifacts

42. Product Backlog
• Using Scrum, we always do the most valuable work first. The
product owner, with input from the rest of the Scrum team and
stakeholders, is ultimately responsible for determining and
managing the sequence of this work and communicating it in the
form of a prioritized (or ordered) list known as the product
backlog.

43. • On new-product development the product backlog items initially
are features required to meet the product owner’s vision. For
ongoing product development, the product backlog might also
contain new features, changes to existing features, defects
needing repair, technical improvements, and so on.
• The product owner collaborates with internal and external
stakeholders to gather and define the product backlog items. He
then ensures that product backlog items are placed in the correct
sequence (using factors such as value, cost, knowledge, and risk)
so that the high-value items appear at the top of the product
backlog and the lower-value items appear toward the bottom.

44. Overall the activity of
creating and refining
product backlog items,
estimating them, and
prioritizing them is
known as grooming

45. • Before we finalize prioritizing, ordering, or otherwise arranging
the product backlog, we need to know the size of each item in the
product backlog
• Size equates to cost, and product owners need to know an item’s
cost to properly determine its priority.
• Scrum does not dictate which, if any, size measure to use
with product backlog items.
• In practice, many teams use a relative size measure such as story
points or ideal days.

46. Sprints
In Scrum, work is performed in iterations or cycles of up to a
calendar month called sprints . The work completed in each sprint
should create something of tangible value to the customer or user.
Sprints are timeboxed so they always have a fixed start and end
date, and generally they should all be of the same duration. A new
sprint immediately follows the completion of the previous sprint.
As a rule we do not permit any goal-altering changes in scope or
personnel during a sprint

48. Sprint Planning
A product backlog may represent many weeks or months of work,
which is much more than can be completed in a single, short
sprint. To determine the most important subset of product backlog
items to build in the next sprint, the product owner, development
team, and Scrum Master perform sprint planning.
During sprint planning, the product owner and development team
agree on a sprint goal that defines what the upcoming sprint is
supposed to achieve.

50. To acquire confidence in what it can get done, many development
teams break down each targeted feature into a set of tasks. The
collection of these tasks, along with their associated product
backlog items, forms a second backlog called the sprint backlog.
The development team then provides an estimate (typically in
hours) of the effort required to complete each task. Breaking
product backlog items into tasks is a form of design and just-in-
time planning for how to get the features done.

52. Sprint Execution
Once the Scrum team finishes sprint planning and agrees on the
content of the next sprint, the development team, guided by the
ScrumMaster’s coaching, performs all of the task-level work
necessary to get the features done (see Figure 2.10), where
“done” means there is a high degree of confidence that all of the
work necessary for producing good-quality features has been
completed.

54. Daily Scrum
Each day of the sprint, ideally at the same time, the development
team members hold a timeboxed (15 minutes or less) daily scrum
(see Figure 2.11). This inspect-and-adapt activity is sometimes
referred to as the daily stand-up because of the common practice
of everyone standing up during the meeting to help promote
brevity.

56. A common approach to performing the daily scrum has the
ScrumMaster facilitating and each team member taking turns
answering three questions for the benefit of the other team
members:
What did I accomplish since the last daily scrum?
What do I plan to work on by the next daily scrum?
What are the obstacles or impediments that are preventing me
from making
progress?

57. Done
In Scrum, we refer to the sprint results as a potentially shippable
product increment, meaning that whatever the Scrum team
agreed to do is really done according to its agreed-upon definition
of done.
This definition specifies the degree of confidence that the work
completed is of good quality and is potentially shippable.
For example, when developing software, a bare-minimum definition
of done should yield a complete slice of product functionality that
is designed, built, integrated, tested, and documented.

58. To be clear, “potentially shippable” does not mean that what got
built must actually be shipped. Shipping is a business decision,
which is frequently influenced by things such as “Do we have
enough features or enough of a customer workflow to justify a
customer deployment?” or “Can our customers absorb another
change given that we just gave them a release two weeks ago?”

59. Potentially shippable is better thought of as a state of confidence
that what got built in the sprint is actually done, meaning that
there isn’t materially important undone work (such as important
testing or integration and so on) that needs to be completed
before we can ship the results from the sprint, if shipping is our
business desire.

60. Sprint Review
At the end of the sprint there are two additional inspect-and-adapt
activities. One is called the sprint review.
The goal of this activity is to inspect and adapt the product that is
being built.
Critical to this activity is the conversation that takes place among
its participants, which include the Scrum team, stakeholders,
sponsors, customers, and interested members of other teams. The
conversation is focused on reviewing the just-completed features
in the context of the overall development effort.

61. A successful review results in bidirectional information flow. The
people who aren’t on the Scrum team get to sync up on the
development effort and help guide its direction.
At the same time, the Scrum team members gain a deeper
appreciation for the business and marketing side of their product
by getting frequent feedback on the convergence of the product
toward delighted customers or users.
The sprint review therefore represents a scheduled opportunity to
inspect and adapt the product.

63. Sprint Retrospective
The second inspect-and-adapt activity at the end of the sprint is the
sprint retrospective. This activity frequently occurs after the
sprint review and before the next sprint planning.
Whereas the sprint review is a time to inspect and adapt the
product, the sprint retrospective is an opportunity to inspect and
adapt the process. During the sprint retrospective
the development team, ScrumMaster, and product owner come
together to discuss what is and is not working with Scrum and
associated technical practices.

65. The focus is on the continuous process improvement necessary to
help a good Scrum team become great. At the end of a sprint
retrospective the Scrum team should have identified and
committed to a practical number of process improvement actions
that will be undertaken by the Scrum team in the next sprint.

66. After the sprint retrospective is completed, the whole cycle is
repeated again—starting with the next sprint-planning session,
held to determine the current highest-value set of work for the
team to focus on.

67. Scrum quote:
“So, why do we do development work in these
short cycles? To learn. Experience is the best
teacher, and the scrum cycle is designed to
provide you with multiple opportunities to
receive feedback—from customers, from the
team, from the market—and to learn from it.”

68. References:
- ESSENTIAL SCRUM :A PRACTICAL GUIDE TO THE MOST POPULAR
A GILE PROCESS . KENNETH S. RUBIN
- Scrum For Dummies : Mark C. Layton
-
SCRUM The Ultimate Beginners Guide To Mastering Scru
m To Boost Productivity & Beat Deadlines : Adam Vardy