Mod 6 - Agile Scrum in a nutshell.pdf

Table Of Content
2
Section 1 Introduction
Section 2 The Agile manifesto and the birth of Scrum
Section 3 Overview of the Scrum Framework
Section 4 Scrum Theory
Section 5 Scrum Values
Section 6 Scrum Artifacts
Section 7 Scrum Events
Section 8 The Scrum Team and accountabilities
Section 9 Scaling Scrum
Section 10 Terms and tools used in Agile and Scrum projects

Agile Manifesto
7
In the 1990s there was a growing movement throughout the software development world. Teams were
growing tired of the traditional way of building software using a waterfall process, where the team first
defines strict requirements, then draws up a complete design, and builds out all of the software architecture on
paper before the code is written.
In 2001, a group of seventeen open-minded people got together. The group included thought leaders from all
across the new “lightweight” world, including the creators of Scrum and XP. They weren’t sure exactly what
would come out of the meeting, but there was a strong sense that these new lightweight methods for
building software had something in common. They wanted to figure out if they were right, and maybe find a
way to write it down.

Agile Manifesto
8
The values and ideas contained in this manifesto were
derived from a larger range of software development
frameworks including Scrum, KanBan, Extreme
Programming and many others. So this is why Scrum is
considered an agile framework and associated with the
agile movement.

Agile Manifesto
9
There’s no single “best” way to build software. The Agile Manifesto is effective because it lays out
values that help teams get into an agile mindset. When everyone on the team genuinely incorporates
these values into the way they think, it actually helps them build better software.

OVERVIEW OF THE
SCRUM FRAMEWORK
10

11
Describes a framework for dealing with complex
work often encountered when developing new
products.
With constantly changing market conditions and
technology improvements, giving a high level of
uncertainty.
It is impossible to predict from the beginning how a
product should be developed.
Overview of the Scrum Framework

12
Case: Spending six months to create a detailed plan with requirements and following that plan for
another one or two years until the final product is ready to be released does not work anymore.
So in these conditions, working with time boxes and quick adaptation. Is mandatory to ensure that a
product does not fail, Scrum is a framework that imposes time box's feedback loops and encourages
small increments while overall trying to deal with uncertainty.
Timebox Adaptation

13
There is a bit of all the steps required to develop a
product, this may include:
- Gathering requirements and understanding
what customers want
- Planning
- Design and Architecture
- Development
- Testing
- Documentation
And to put them in a fixed length iteration, call a
Sprint. So a sprint combines all aspects of the
work required to build a product.

14
- Right from the first sprint, a scrum team will try to create a valuable and usable product even if it is
not released to the customers or end users.
- After each sprint, the scrum team demonstrates what they have accomplished and discussed what to
do next. Customers often need to see the wrong product before they can see what they really want.
- The short iterations allow for constant feedback and improvement, this considerably increases the
probability of creating the right product, a product that customers use and love.
- In order to accomplish that, the team needs to have all the necessary skills to understand the
business requirements, to do any design, development and testing work so that by the end of the
sprint, a valuable and usable product is created.
Sprint 1 Sprint 2 Sprint 3

15
- A scrum team consists of a scrum master, a product owner and the developers.
- The product owner will create a list of features called the product backlog and organize that list to ensure
that customers get the maximum amount of value.
- During sprint planning, the developers will select list of items from the top of the product backlog, work
on them during the sprint and turn them into a usable product (increment product). Increment is simply a
new version of the same product.

16
- The Scrum team has a fixed time frame to complete a work which cannot be longer than one
month, and the developers meet in a daily scrum to synchronize, identify problems and keep the
work moving forward.
- Along the way, the scrum master keeps the team focused on the sprint goal and helps remove any
impediments that affect them.

17
- At the end of the sprint, the product increment should be valuable and usable and a scrum team,
together with the stakeholders, conduct a review of the work completed and discuss what to do next.
- The last event of the sprint is a retrospective of the process, the scrum team looks back at how the
sprint went and figured out a way to improve their development process.
- Then they start from the beginning with the next sprint planning and the cycle repeats.

18
What Scrum is actually used for
Scrum has been used to:
● Develop and sustain product enhancements
● Sustain or renew products
● Research and identify markets, technologies and product capabilities
It's important not to associate Scrum only with software development. I know that Scrum is especially known in
the software industry and it has been tremendous successful but Scrum is not only about developing software.
Scrum has been used to:
● Develop hardware / software
● Build autonomous vehicles
● In schools and governments
● In marketing
● Or anywhere

20
Scrum Theory - What does this means?
- Scrum is actually founded on the Empirical Process of control theory, also called Empiricism. And
lean thinking
- And Empiricism asserts that knowledge comes from experience. You need to make a decision
based on what is known at this point and what actually
- Lean thinking reduces waste and focuses on the essentials.
- Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
- What is important regarding this Empirical Control Process that is build on three pillars:
- Transparency,
- Inspection,
- and Adaptation

21
Transparency
- The emergent process and work must be visible to those performing the work as well as those
receiving the work. Observers need have a common understanding of what is being seen.
- Transparency enables inspection. Inspection without transparency is misleading and wasteful.
- E.g:
- At the Daily Scrum, everyone on the team know each other's work.
- If you have like technical people discussing with business people if they don't share the same
language it's kind of hard to discuss about what is being observed.
- The Increment must share a common "Definition of Done".

22
Inspection
- The Scrum artifacts (product backlog, sprint backlog, increment) and the progress toward agreed
goals must be inspected frequently and diligently to detect potentially undesirable variances or
problems. (but it should not really get in the way of getting work done)
- To help with inspection, Scrum provides cadence in the form of its five events (Sprint Planning,
Daily Scrum, Sprint Review, Sprint Retrospective, Sprint itself).
- Inspection enables adaptation. Inspection without adaptation is considered pointless.
- Scrum events are designed to provoke change.

23
Adaptation
- If any aspects of a process deviate outside acceptable limits or if the resulting product is
unacceptable, the process being applied or the materials being produced must be adjusted.
- The adjustment must be made as soon as possible to minimize further deviation.
- Adaptation becomes more difficult when the people involved are not empowered or self-managing.
A Scrum Team is expected to adapt the moment it learns anything new through inspection.

25
Scrum values
- The Scrum values make the team more effective
- Scrum comes with its own set of five values that do exactly the same thing as Agile Manifesto for
Scrum teams.
- Commitment,
- Focus,
- Openness,
- Respect, and
- Courage

26
Scrum values - Commitment
- Every person on the team is committed to delivering the most valuable product that they can—and
supporting each other.
- Every Scrum role has a distinct accountability, and this is a commitment:
- The Product Owner demonstrates commitment by making the best decisions to optimize
the value of the product, not simply trying to please every stakeholder.
- The Developers demonstrates commitment by creating an Increment that meets their
definition of "Done", not something that is almost done.
- The Scrum Master demonstrates commitment by upholding the Scrum Framework, which
means we don't extend the Sprint or other time-boxes under pressure to get to "Done." The
Scrum Master demonstrates commitment by removing impediments that the Scrum Team
cannot resolve themselves, rather than accept the status quo in the organization.

27
Scrum values - Focus
- Every team member is focused on the Sprint Goal, and everything they do in the Sprint helps move
them toward it.
- During the Sprint, everyone works only on Sprint tasks, and does one task at a time and moves on
to the next task only when the current one is done until the Sprint is done.

28
Scrum values - Openness
- We always know what our team members are working on, and are comfortable that they know what
you’re working on.
- If we run into a problem or an obstacle, we can bring it up with the team.

29
Scrum values - Respect
- Scrum Team members respect each other to be capable, independent people, and are respected as
such by the people with whom they work.

30
Scrum values - Courage
- The Scrum Team members have the courage to do the right thing, to work on tough problems.

31
The most important ideas regarding the Scrum framework
- Scrum is a framework for developing complex products
- Scrum addresses complex problems in an iterative way
- Scrum is lightweight, simple to understand but difficult to master
- The Scrum framework consists of Scrum Teams and their associated accountabilities, events,
artifacts, and rules.
- Scrum is used in very diverse areas, from developing software and hardware to managing the
operation of organizations and almost everything we use in our daily lives, as individuals and
societies.
- The essence of Scrum is a small team of people
- Scrum is founded on empirical process control theory, or empiricism.
- Three pillars uphold every implementation of empirical process control: transparency, inspection,
and adaptation.
- The Scrum Values are: commitment, courage, focus, openness and respect

33
Scrum Artifacts
- The scrum guide defines three artifacts: product backlog, sprint backlog, Increment
- Scrum artifacts represent work or value. They are designed to maximize transparency of key
information. Thus, everyone inspecting them has the same basis for adaptation.
- Each of the scrum artifacts contains a commitment to something
- The product backlog exists to reach the long term objective - product goal
- The sprint backlog exists to reach the sprint goal that the scrum team defines for every sprint.
Each sprint goal is a step toward achieving the goal.
- The product increment is committed to fulfilling the definition of done, which usually describes
the desired quality that the product should have.
PRODUCT BACKLOG
SPRINT BACKLOG
INCREMENT
PRODUCT GOAL
SPRINT GOAL
DEFINITION OF DONE
*A commitment means to be dedicated to achieving something specific. Having a commitment ensures that everyone knows why the work is
important and what is the desired outcome.

35
What is Product Backlog?
- In scrum, the product backlog is an artifact designed to provide transparency and opportunities for
inspection and adaptation.
- The product backlog is an ordered list of everything that is needed in the product. Can contain new
features or improvements to existing once, fixes or any other changes that need to be done on the
product.
- The items in the product backlog are referred to as product backlog items or simply PBIS.

36
What is Product Backlog? (cont.)
- The characteristics of a backlog item depend on the product or the domain where the development
work takes place, typically an item will have attributes like:
- Description
- Order
- Size
- Value
- Acceptance criteria (to test if the work is complete)
- The sole person accountable for the product backlog is
the product owner, we call the activity of making changes
to the product backlog - product backlog management.

37
How exactly is the product backlog created and managed?
- Everything starts with a goal or a vision.
- The product owner is expected to define an objective that a product should achieve. This is the
product goal.
- The product owner try to understand the business requirements by constantly collaborating with the
stakeholders, knowing the market conditions and considering any other relevant information
sources.
- The product owner will add features or ideas to the product backlog as they deem relevant for a
product, but the product backlog content (PBIS) needs to be aligned with the product goal.
- The product goal is a commitment for the product backlog and is a part of it.
- There's only one product goal at a time.

38
- Managing the product backlog is an ongoing process, while the product owner is accountable for
the product backlog and can order, add or remove product backlog items any time they want.
- Product Owner closely work with the developers. During the product backlog refinement
activity, the product owner and the developers collaborate on breaking down larger items into
smaller ones that are easier to describe and develop. The smaller the items, the better it is.
- It will also work on adding details, size and order to the product backlog.
- The size of an item shows how big or small the effort of doing the work is, the process of figuring out
the size of an item is called sizing or estimation. The developers doing the work are responsible
for sizing and have the final say.

39
- The product owner and the developers collaborate to understand the items and often look for ways
to reduce complexity by making tradeoffs.
- Refinement activity is not part of the mandatory scrum events, the scrum team decides if, how
and when refinement is done.
- The product backlog is emergent and never complete or final. It is constantly changing the product
backlog growth with the product itself and changes based on business requirements, market
conditions or other relevant factors.
- The product backlog items that can be done in the next sprint are deemed as ready for selection.
This means that the items are small enough to fit within a sprint, detailed enough and
immediately actionable, meaning that the developers can start working on them right away.
PRODUCT GOAL
1000 online orders per day in
the next 1 year
PRODUCT BACKLOG
1. Create Homepage
2. Display one product
3. Display list of products
4. Order form
5. Add to cart
6. Online payment

40
User stories
- User stories are relatively short descriptions of a feature explained from the perspective of the
person who desires the functionality. Usually a user of the product.
- Commonly, when writing user stories, you go through a three step process (also known as the 3
Cs):
- Card
- Conversation
- Confirmation

41
User stories
- The card refers to the people card size, used to write the user story, usually a Sticky note.
- The main idea of the card remains the same because the card can only hold so much information.
We need to be brief. A template for a user story typically looks like this (but feel free to adapt)
CREATE HOMEPAGE
As a customer interested in ABC
products
I want to open a browser and use some
basic contact information
So that can help me get in touch.

42
User stories
- Another way of looking at the user story format is identifying the WHO, the WHAT and WHY.
- Often it brings value to the conversation is understanding the way the benefit of implementing the
user story, we don't want to build things that have no value and nobody wants it mentioned an
important aspect of conversation. This is the second C.
- The information contained by the product backlog item should be brief and to the point, think of the
items more like a reminder of what needs to be done. A conversation starter, not necessarily
detailed specification. This activity helps to have the same understanding of the work to be done.

43
User stories
- The last C is confirmation. We commonly refer to this as acceptance criteria. It is a way to test if
the story has been completed.
CREATE HOMEPAGE
products
ACCEPTANCE CRITERIA
- I should see the logo of ABC
- I should see the postal address,
the email address and phone
number

44
User stories
DISPLAY ONE PRODUCT
As a customer interested in
products from ABC,
I want to open a browser and find
some basic information about a
Apple Juice product to be better
informed about the ingredients and
available sizes.
BACKGROUND
The Apple Juice is the best selling product at ABC. A
lot of customers ask questions about a product
acceptance criteria.
ACCEPTANCE CRITERIA
The start page should include a button called Our
Product
When Clicked. It should open a new page. The
products page.
The product page should display one or more images
of the product. The product page should include a short
description. The product page should include an FAQ
U.S. with questions and answers.
- The product backlog item is written as a user story, but this doesn't mean that every item in the
product backlog needs to be written using this format.
- The Scrum team decides which format works best. It is OK to have different formats in the same
backlog use.

45
User stories
- Backlog is by no means complete nor it will ever be more product backlog items will be created
and refined in the following sprint as more is learned about the product.
- While the product owner is accountable for the product, backlog content and order. It does not mean
that the rest of the scrum team cannot write product backlog items or user stories and discuss them
with a product owner. However, the product owner still remains accountable.

46
Estimation or Sizing
- The stories now have a description, acceptance criteria and order as they are the first and second
items in the backlog.
- The next step would be to take this product back, look item written as a user story and discuss it
with the clarify details, see if the order makes sense and get an estimate. The words estimation or
estimate, size or sizing. They are referring to the same thing.
- This collaboration between the product owner and the developers happens during the product
backlog refinement activity.
ESTIMATE
- An estimate in the usual sense is a guess of the effort necessary to carry out a given task.
- In our case, one product backlog item. It is a guess, not a commitment or a promise, there is
always some uncertainty and that is fine.

47
QUESTION: So it means we should say how long it will take us in days?
ANSWER:
- That would be an option, but is not the best way to think about this.
- As in a lot of other aspects, Scrum is different from classic project management methods. You see,
humans are good at comparing things, for example, which building is higher than the one next to it.
We have a good intuition at comparing things without actually need to know the exact height or the
number of flaws each building has. We call this a relative sizing at the same time.
- Studies have shown that people are terrible at guessing the building's actual height. This would be
absolute sizing.
- So when building a feature, we want to know the size first. Is it just a small or big?
CREATE HOMEPAGE
products
ACCEPTANCE CRITERIA
number

48
A: How to proceed?
7 14 19 30
B: A scale imagined that 0 is changing the color of homepage background, almost no effort and 100 is
proceed online payment. This would be the start and the end of the scale could, pick a number between
zero and 100 that you think represents the effort of building a functionality. There's no wrong or right here.

49
8 13 20 20
B: Now, let's imagine that you can only pick one of the following numbers 0, 1, 2, 3, 5, 8, 13, 20, 40 and
100. This is an estimation technique called planning poker.

20 20 20 20 50
A: Well, this is a simple page with the logo and subtext. No big deal.
B: Now, we only have 8, 13, 20 and 20 looks much better than what we have started with. Let's now
discuss your estimates and try to reach a consensus, OK, you had an eight one for your reasons why?
C: Have you considered that we need to have an admin panel to added that information?
A: Oh, I'm afraid I've only estimated the design work. All right, one, let's try again.

8 8 8 8 51
A: Is there anything I can change regarding the product backlog item in order to reduce the complexity?
B: I guess the admin panel is something that is driving complexity up. OK, I'm more than happy to leave
that out, at least for the moment. Can you estimate the product backlog item again, this time without the
admin panel?

52
B: It has no meaning, we are not talking about eight hours, eight days or anything else.
- This is relative sizing.
- However, we will use this story as a reference. When estimating other stories, we will ask ourselves
if another story is smaller or bigger than this one later on, as we learn more, we may even agree to
go back to the story and estimate it again.
CREATE HOMEPAGE
products
ACCEPTANCE CRITERIA
number
8

53
Product Backlog Refinement
- The Product Backlog is continuously changing and evolving, and managing the Product Backlog
is something that a Product Owner cannot do without getting input from the rest of the Scrum Team.
- The Product Backlog Refinement is an ongoing activity, but this meeting is not part of the
prescribed Scrum events. This means that the Scrum Team decides how and when refinement is
done. As there are no pauses or gaps between Sprints, this meeting can happen any time during
the Sprint.
- Nevertheless, the Product Backlog Refinement still has a time-box, in the sense that it should not
occupy more than 10% of the capacity of the Scrum Team.
- This activity is not connected to the Sprint goal but very important for preparing the next Sprints. The
goal of this meeting is to have enough Product Backlog Items at the top of the Backlog "ready"
for selection in the next Sprint Planning. This activity can even take place during the Sprint Planning
itself, but ideally, most of the Items should have been refined already.
- During the Product Backlog Refinement meeting, the Product Owner and the Scrum Team, work on
making sure that the items are small enough to fit in one Sprint and add details, estimates, and
order to the Product Backlog.
- Not all items in the Backlog need to reach the level of detail that Items at the top have. This is
an efficient way of eliminating waste and making sure that time is efficiently used.

54
Product Backlog Refinement
- Typically the Product Owner will come with new ideas, features, or fixes and will try to express
them in Product Backlog Items.
- The Product Owner and the Scrum team will collaborate on clarifying any questions and making the
items as clear as possible.
- However, the Product Backlog can be changed at ANYTIME by the Product Owner, not only during
this meeting.
- The Developers will be asked to estimate the items in the backlog. The Product Owner may offer
alternatives or make trade offs to reduce the complexity and to get a better estimate. But what is
important to remember is that the Developers is responsible for all estimates and it has the final
saying.

56
Sprint Backlog
SPRINT PLANNING
SPRINT GOAL SPRINT BACKLOG

57
Sprint Backlog
- During the sprint planning meeting, the product owner explains what needs to be done next to
increase the value of the product, and the entire scrum team formulates a sprint goal.
- By collaborating with a product owner, the developers will decide which items starting from the top
of the product backlog will be added to the sprint backlog.
- The sprint backlog will also contain a plan to deliver the product increment and realize the sprint
goal.
Sprint Goal

58
Sprint Backlog
PRODUCT BACKLOG
- The product backlog is an ordered list
of ideas or features the product should
or could have basically everything that
could be done.
- We call these items in the list product
backlog items.
SPRINT BACKLOG
- The sprint backlog is created from
scratch at the beginning of every
sprint and contains:
- the product backlog items that
will be done in the current sprint
- a plan on how to deliver the
functionality and
- the sprint goal.
- All items in the sprint backlog come from
the product backlog.

59
Sprint Backlog
- A plan is essentially a decomposition of each product backlog item in smaller work units that
allow the developers to build the increment. We often call the smaller units of work tasks.
- Many people learning scrum quite often forget that a sprint backlog also contains a plan and the
sprint goal, not just the selected items, don't make the same mistake.
- WHY: The sprint goal gives guidance and flexibility and explains why the sprint is valuable.
- WHAT: The product backlog items represent what will be delivered.
- HOW: The plan handles how this will happen
SPRINT
BACKLOG
CREATE HOMEPAGE
- Creating Git Repository
- Create the simple HTML page -
Create deployment pipeline that will
help them automatically publish any
changes
- Set up the hosting account
- Test the website on multiple
browsers
Sprint Goal

60
Sprint Backlog
- When the developers select the product backlog items, they think that can be completed in a sprint,
they create a forecast for what will be delivered.
- The sprint forecast is not a guarantee, a promise or a commitment. Unexpected things may
happen during the sprint.
- The sprint backlog makes transparent all the work that the developers deem as necessary to reach
the Sprint Goal, which represents the commitment that the sprint backlog has.
- You can do the sprint backlog as a temporary artifact that exists only during the sprint. Every
sprint will have a new sprint backlog.
- Any unfinished work that remains in the sprint backlog at the end of the sprint will be put back
into the product backlog. The product owner will decide what should happen next.
- Product backlog is the product owner's accountability # The sprint backlog, the developers are
accountable.
- The developers will modify the sprint backlog throughout the sprint as they think it is necessary to
reach the sprint goal when they identify new work that needs to be done, they immediately added to
the sprint backlog.
- The total work remaining in the sprint backlog will be tracked at least once with every daily
scrum, the developers are responsible for monitoring the progress toward the sprint goal.

61
Sprint Scope vs Sprint Goal
- One of the most confusing parts of Scrum is understanding the difference between the sprint scope
and the sprint goal.
- The sprint scope can be renegotiated
- The sprint goal remains the same
Weekend plan
Have a great picnic
Search for place
Invite friends
Buy camp
Check weather forecast
GOAL
SCOPE
What you want to do +
the extent of the work
If during the day you notice that you are running behind your plan, you may reduce the scope, for
example, you decide to book a hotel instead of buying a camp.
FOCUS

62
Sprint Scope vs Sprint Goal
- The Sprint Scope represents the functionality that will be developed during the sprint.
- The scope of the sprint backlog is the amount of work selected by the developers, in other
words, the selected product backlog items.
- The scope is flexible and can be modified during the sprint.
- The terms Scope = Sprint scope = Scope of the sprint backlog
- With the time available, the developers will try to stay focused and do their best to reach the sprint
goal.
- The scope renegotiation with the product owner can happen any time. The idea is to meet the
sprint goal while making some compromises, usually in terms of features, NEVER ON QUALITY.
- In this process, the product owner and the developers decide which is the best course of action.
Some items in the sprint backlog may not directly contribute to reaching the sprint goal. Others
can be simplified. Items can even be replaced with other items from the product backlog.
Anything is possible as long as the sprint goal is not in danger.
- In practice, it is rarely the case that the entire spring backlog will contribute to reaching the Sprint
Goal, while most of the items in the sprint backlog must be related and must help reach the sprint
goal. It is not always possible to have a sprint backlog that only focuses on reaching the spring goal.
And this is also the part that allows for some flexibility to happen.

64
Increment
- The increment is a new version of the product and is additive to all previous increments from all
previous sprints (you can view it like a building block placed on top of all previous work completed)
- The developers were to deliver at least a new product increment with each sprint.
- Each new increment is an improved and usable version of the product.
- It is solely the discretion of the product owner if and when to release the increment, still, the
increment needs to be usable without needing any additional work, like testing, documentation
or even integrating it with the work other scrum teams did.

65
Definition of Done
- When a product backlog item or increment is considered a complete or done, everybody must
understand what DONE means.
- Sometimes the organization may define quality standards and those need to be followed at a
minimum to make it easier for everybody to understand what complete work looks like. The
definition of done is mostly about quality.
Definition of Done
- Organic ingredients
- Raw materials
- The logo must be visible
on the product
- The product label must
indicate the number of
calories, sugar
- Conforms with health
and safety standards.
Definition of Done
- The Acceptance criteria of each
item
- Code was reviewed
- Unit tests
- Technical documentation
- Acceptance tests
- Desktop cross-browser testing:
safari, chrome
- Mobile device testing: Iphone >
5, Android > 5
- CI/CD
Definition of Done
Non-Functional Requirements
- Performance: each transaction
complete < 2 seconds
- Availability: 1000 concurrent
transactions
- Security: customer data must be
secured

66
Definition of Done
- In scrum, each Sprint will create at least one product increment that needs to adhere to the
definition of done.
- If a product backlog item in the sprint does not follow the definition of done, it will not be included
in the product increment.
- When Scrum team gains more experience, It is expected that the definition of done will contain
more strict criteria to ensure higher quality.
- During the Sprint retrospective, the Scrum team plans on how to increase product quality and one
way to ensure this is by adapting the definition of done.
- There is no standard on what the definition of done should include, as this can vary from team to
team and from product to product.
- By using a definition of done, it becomes transparent for everyone what it means for the product
increment to be done.
- The definition of done will also guide the developers on how many product backlog items to
choose during the spring planning meeting.
- The definition of done represents a commitment for the increment. As soon as one product
backlog item is completed and meets the definition of done, a new increment is created.

67
Definition of Done vs. Acceptance Criteria
- We use the definition of done is very general, makes no reference to particular functionality.
The definition of done tends to be more technical talk about code, quality, code coverage, security,
best practices.
- Acceptance criteria are specific to a particular item, the acceptance criteria tries to describe when
an item is complete, mostly from a functional perspective.
- Acceptance criteria apply to a single PBI, while the definition of done applies to that PBI + to
the entire product increment.
- For one product backlog item to be released to the users, it needs to meet the acceptance criteria
(if they exist) and the definition of done. A definition of done explicitly mentions that the
acceptance criteria must be fulfilled.
- The increment created from one or more PBIS also needs to meet the definition of done.
Definition of Done Acceptance Criteria
- Applies to every PBI & Product Increment
- Created by Scrum team
- Commitment to Increment
- Mandatory in Scrum
- Applies to a single PBI
- Created by Product Owner (accountable)
- Part of a PBI
- Optional in Scrum

69
Scrum Events
- Scrum uses prescribed events or meetings or ceremonies, to reduce the need for other meetings
that are not defined in scrum.
- This does not mean that the Scrum team cannot have other meetings, but it is mandatory to have
the scrum events.
- At the heart of Scrum is the sprint, which acts as a container for all scrum events. Remember that
there are no pauses or gaps between sprints and everything happens within the sprint container.
- For this reason, the sprint is a special kind of an event. All events within Scrum have a maximum
duration and are therefore - Time-boxed.
- Events are designed to enable transparency and inspection. There are recommends that the
events are held at the same time and place to create a routine and to reduce complexity.
- Sprint planning, where the work to be performed in the sprint is planned.
- The daily scrum, which is held every day of the Sprint
- Sprint Review, which is held at the end of the sprint to review the increment.
- And Sprint retrospective, which is an opportunity to discuss ways to improve our all scrum events,
which are a former opportunity to inspect and adapt
- In other words, all scrum meetings are an excellent opportunity to get feedback and to take action
based on the feedback received.

70
Scrum Events
- These events are mandatory and team cannot simply decide to skip or postpone them.
- While Scrum makes these events mandatory, it does not mean that the scrum team cannot have
other meetings. It is a common misconception to assume that any discussions within the scrum
team or between the scrum team and the stakeholders must happen in a scrum event.
- The product backlog refinement activity is not a mandatory scrum meeting and it is not
considered a scrum event.
SPRINT
SPRINT PLANNING DAILY SCRUM SPRINT REVIEW
SPRINT RETROSPECTIVE

71
Sprint
- A Sprint has a time-boxed of one month or less in which a valuable, usable Product Increment is
created.
- If the duration of the Sprint is too long, the complexity and risk may increase.
- Having these relatively short horizons it is also easier to plan what is being built and to get
early feedback.
- Sprints contain all the prescribed Scrum Events, a flexible plan on how to build a Product
Increment and of course the development work needed.
- Each Sprint has the Sprint Goal which is an objective that will be met within the Sprint time-box
and which helps the Development Team better understand WHY it is building the Increment.
- During the Sprint, no changes should be made that would endanger the Sprint Goal.
- It is also important that the quality standards do not decrease, especially if the time-box is about
to expire.
- As the product increment is being built, new things are learned. When necessary, the scope of the
Sprint may be clarified and renegotiated between the Development Team and the Product Owner.
- A new Sprint starts immediately after the previous Sprint has ended. There is no gap between
Sprints and nothing happens between Sprints.

73
Cancel a Sprint
- Canceling a Sprint before the time-boxed expires is a very very rare occurrence. I
- A Sprint can be canceled if the Sprint Goal becomes obsolete or if there are some major and
sudden changes on the market or if the company decides to change direction.
- Only the Product Owner has the authority to cancel the Sprint. It may do so if advised by the
Stakeholders, the Developers or the Scrum Master but only Product Owner can take this decision.
- If a Sprint is canceled, the Product Backlog Items that are completed will be reviewed. Incomplete
Backlog Items will be re-estimated and put back into the Product Backlog.

74
Sprint Planning
- The Sprint Planning is a time-boxed to a maximum of eight hours for a one-month Sprint. For
smaller Sprints it should be smaller.
- This event happens usually after the conclusion of the previous Sprint.
- During the event, the Product Owner and the Development Team will agree on a Sprint Goal and
discuss which Items from the Product Backlog will be added to the Sprint Backlog.
SPRINT GOAL SPRINT BACKLOG

75
Sprint Planning
- The Product Owner proposes how the product could increase its value and utility in the current
Sprint.
- The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint
is valuable to stakeholders.
- The Sprint Goal must be finalized prior to the end of Sprint Planning.
Step 1: Why is this Sprint valuable?
SPRINT GOAL

76
Sprint Planning
- The Developers will work to forecast what can be done in the Sprint. The number of Product
Backlog Items selected is solely up to the Developers.
- In order to make the above mentioned forecast. The Scrum Team has a few details they need to
take into account, which are their Definition of Done + the projected capacity of the Developers +
the past performance of the Developers.
Step 2: What can be Done this Sprint?
Definition of Done
Projected Capacity
Past Performance

77
Sprint Planning
- For each selected Product Backlog item, the Developers plan the work necessary to create an
Increment that meets the Definition of Done.
- This is often done by decomposing Product Backlog items into smaller work items of one day or
less.
- How this is done is at the sole discretion of the Developers. No one else tells them how to turn
Product Backlog items into Increments of value.
Step 3: How will the chosen work get done?
Sprint Goal

78
Daily Scrum
- The Daily Scrum is a time-boxed (15-minute) event held at the same time and place each day to
reduce complexity.
- The Daily Scrum is held every day during the Sprint and it is an event intended for the Developers.
During this event the Development Team plans what work will be performed in the next 24
hours.
- The Daily Scrum is a key "inspect and adapt" meeting in Scrum. The Developers can select
whatever structure and techniques they want, as long as their Daily Scrum focuses on
progress toward the Sprint Goal and produces an actionable plan for the next day of work. This
creates focus and improves self-management.
- If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they
participate as Developers.
- Daily Scrums improve communications, identify impediments, promote quick decision-making,
and consequently eliminate the need for other meetings.
- The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet
throughout the day for more detailed discussions about adapting or re-planning the rest of the
Sprint’s work.

79
Daily Scrum
What did I do yesterday?
What will I do today?
Do I see any impediment?
- During this meeting the role of the Scrum Master is to make sure that the Developers has the
meeting and it is teaching to keep it within the time-box.
- While this is an internal meeting, the Developers could allow for others to be present. The Scrum
Master ensures that they do not disturb the meeting. This is a meeting for the Developers and not
for reporting the progress toward a Product Owner or the Stakeholders.

80
Sprint Review
- The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future
adaptations. The Scrum Team presents the results of their work to key stakeholders and progress
toward the Product Goal is discussed.
- During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint
and what has changed in their environment. Based on this information, attendees collaborate on
what to do next.
- The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a
working session and the Scrum Team should avoid limiting it to a presentation.
- It is a timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the
event is usually shorter.
- The Sprint review is an informal meeting not a formal status meeting.
- This meeting is not only a good opportunity for the Scrum Team to gather feedback but also for the
Stakeholders to ask questions or to suggest changes or new features to the Product Owner.

81
Sprint Review
- The Product Backlog Items that have not been done yet or that are not fully done. For example
some functionality has not been built or more testing is needed and that is not completed yet.
- So first of all there will NOT be demonstrated during this meeting and they should not be part of
the Product Increment. They will be put back in the Product Backlog.

82
Sprint Retrospective
- The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
- This Sprint Retrospective is the very last event in the Sprint, right after the Sprint Review But prior to
the next Sprint Planning.
- The Scrum Team inspects how the last Sprint went with regards to individuals, interactions,
processes, tools, and their Definition of Done.
- The Scrum Team discusses what went well during the Sprint, what problems it encountered, and
how those problems were (or were not) solved.
- The Scrum Team identifies the most helpful changes to improve its effectiveness. The most
impactful improvements are addressed as soon as possible.
- They may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective
concludes the Sprint.

83
Sprint Retrospective
- It is timeboxed to a maximum of three hours for a one month Sprint. For shorter Sprints, the
event is usually shorter.
- The Sprint Retrospective is an internal Scrum Team event where no external parties are involved.
Having Stakeholders or Management involved in this meeting would most likely inhibit the team
towards openly discussing the problems they see and would reduce the effectiveness of the
meeting. Any discussion with external parties regarding the improvement of the process should be
done outside of this event.
- The Scrum Master acts as a facilitator for this meeting, makes sure that everybody understands
the purpose and ensures that the meeting is positive and productive and coaches a team to keep
the event within the time-box.
https://www.atoha.com/blogs/kien-thuc/agile-retrospectives-nhin-lai-va-cai-tien-hieu-qua-cong-viec-du-an

SCRUM TEAM AND
ACCOUNTABILITIES
84

85
Scrum team
- The fundamental unit of Scrum is a small team of people, a Scrum Team.
- The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.
- Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals
focused on one objective at a time, the Product Goal.

86
Scrum team
- Scrum Teams are cross-functional, meaning the members have all the skills necessary to create
value each Sprint.
- They are also self-managing, meaning they internally decide who does what, when, and how.
- The Scrum Team is small enough to remain nimble and large enough to complete significant work
within a Sprint, typically 10 or fewer people.
- In general, we have found that smaller teams communicate better and are more productive. If
Scrum Teams become too large, they should consider reorganizing into multiple cohesive
Scrum Teams, each focused on the same product. Therefore, they should share the same
Product Goal, Product Backlog, and Product Owner.

87
Scrum team
- The Scrum Team is responsible for all product-related activities from stakeholder collaboration,
verification, maintenance, operation, experimentation, research and development, and anything else
that might be required.
- They are structured and empowered by the organization to manage their own work. Working in
Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
- The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
Scrum defines three specific accountabilities within the Scrum Team: the Developers, the
Product Owner, and the Scrum Master.

88
Product Owner
- The Product Owner is accountable for maximizing the value of the product (business value,
value of customers, technical value,...) resulting from the work of the Scrum Team. How this is done
may vary widely across organizations, Scrum Teams, and individuals.
- The Product Owner is also accountable for effective Product Backlog management, which
includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
- The Product Owner may do the above work or may delegate the responsibility to others.
Regardless, the Product Owner remains accountable.
- For Product Owners to succeed, the entire organization must respect their decisions. These
decisions are visible in the content and ordering of the Product Backlog, and through the inspectable
Increment at the Sprint Review.
- The Product Owner is one person, not a committee. The Product Owner may represent the needs
of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do
so by trying to convince the Product Owner.

89
Developers
- Developers are the people in the Scrum Team that are committed to creating any aspect of a
usable Increment each Sprint. Who have all the skills in order to do the work needed.
- The specific skills needed by the Developers are often broad and will vary with the domain of work.
However, the Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals.
- It is possible for the Product Owner or the Scrum Master to be part of the Developers if they are
doing the work of the Sprint Backlog. But this is not really recommended because then it would be a
mixture between the roles and responsibilities.

90
Scrum Master
- The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
- They do this by helping everyone understand Scrum theory and practice, both within the Scrum
Team and the organization.
- The Scrum Master helps those outside the Scrum Team (for example the Stakeholders)
understand which of their interactions with the Scrum Team are helpful and which aren't.
- The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling
the Scrum Team to improve its practices, within the Scrum framework.
- Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

91
Scrum Master serves the Scrum Team
- Coaching the team members in self-management and cross-functionality;
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

92
Scrum Master serves the Product Owner
- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Helping establish empirical product planning for a complex environment; and,
- Facilitating stakeholder collaboration as requested or needed.

93
Scrum Master serves the Organization
- Leading, training, and coaching the organization in its Scrum adoption;
- Planning and advising Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact an empirical approach for complex
work; and,
- Removing barriers between stakeholders and Scrum Teams.

95
Multiple Scrum Teams work on the same Product
- When there is one Product there can only be one Product Backlog and only one Product Owner.
- There will be a new Developer team and a Scrum Master. The existing Scrum Master can handle
both teams, or can be two different persons. The Product Owner will be the same person.
- During the sprint planning meeting, the representatives from each Scrum Team and the Product
Owner will collaborate on finding solutions that make sense for them.
- When multiple Scrum Teams start working on the same Product, different challenges arise. The key
concern, in this case, is to reduce dependencies between the Teams.
- Generally, it is less of a concern if there's enough work for every Team or how is the velocity of
every team.

96
How many Product Owners are there?
- The rule is pretty simple. For one Product, there can only be one Product Backlog and one
Product Owner.
- Only one person is responsible
- Clear decision-making process.
- There is no Chief Product Owner or Proxy Product Owner

TERMS AND TOOLS USED
IN AGILE AND SCRUM
PROJECTS
97

98
Burndown chart
- Once a team has assigned a story point
value to all of the user stories in the sprint
backlog, they can use burndown charts to
get a handle on how the project is
progressing.
- A burndown chart is a simple line chart
that shows how many story points are
completed each day during the sprint.
- The burndown chart gives everybody a
clear sense of how much work is left to be
done at any time.
- Using a burndown chart, it’s clear to
everyone on the team how close they are
to achieving their sprint goals.

99
Burndown chart
- Burndown Charts are only related to the
remaining work
- NOT related to the project costs or the
business value
- NOT related to the productivity of the team
or to the individual team member.

100
Burnup chart
- Another way to track your progress during
a sprint is to use a burn-up chart.
- Instead of subtracting the number you’ve
completed from the number you committed
to, burn-ups track a cumulative total
throughout the sprint and show the total
committed scope on a separate line.
- When stories are added or deleted from
the scope it’s obvious by looking at the
scope line.
- When stories are put into the “Done”
column on the task board, that’s easy to see
too, by looking at the total number of
points burned up in the sprint.
- Because the scope is tracked on a different
line from the number of points
accomplished, it’s clearer when the scope
is changing.
Scrum does not enforce any of the reporting
tools and charts mentioned. It is totally up to
the Scrum Team which tools to use.

101
Velocity
- At the end of each sprint, you can count
the total number of story points that have
been accepted by the Product Owner. The
number of points per sprint is called the
velocity, and it’s a great way to gauge
how consistently the team is delivering
work.
- During the Sprint Planning meeting, the
Developers will select a number of
Product Backlog Items or User Stories
from the Product Backlog.
- If each has an estimation in story points at
the end of the Sprint, it is easy to see how
many User Stories were completed and
what is the total number of story points
for the Sprint.
PRODUCT BACKLOG
Contact page
Display multi products
Add to cart
SPRINT BACKLOG
Create homepage
Display one product
Order form
8
13
8
29

102
Velocity
- The velocity is calculating by averaging the amount of work performed in the previous Sprints.
- Typically only completed stories are taking into consideration.
- And more sprints are included, the more accurate the value is.
- The team may track its velocity, but it is not required.
- Velocity is NOT correlated with value.
- The forecast in story points that the team makes, is just an estimation, NOT a commitment.
VELOCITY =
Work Sprint 1 + Work Sprint 2 + Work Sprint 3 + … + Work Sprint N
Number of Sprints

103
Velocity Chart
- Many teams plot their velocity per sprint
as a bar chart so they can see how they
did across multiple sprints.
- Since each team’s scale for estimating
story points is different, you can’t use
velocity to compare teams to one
another. But you can use it to help figure
out how much work your team should
commit to based on their past
performance.

104
Sustainable pace
- When doing development work, it is important to be able to have a constant output.
- If the team is delivering more features but, for example, is working overtime, this is not a
sustainable pace.
- While one Sprint may have good results, others may have rather poor. Working overtime to
complete a Sprint or reach the Sprint Goal is not acceptable in Scrum.
- Scrum is about finding a good balance and keeping everyone happy. Think about if the team is
constantly under stress, the developers will be unhappy. Some may sooner or later decide to leave
the team/company.
- There might be short-time gains but in the long-term this cannot be good.

Mod 6 - Agile Scrum in a nutshell.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Mod 6 - Agile Scrum in a nutshell.pdf

Similar to Mod 6 - Agile Scrum in a nutshell.pdf (20)

Recently uploaded

Recently uploaded (20)

Mod 6 - Agile Scrum in a nutshell.pdf