Empiricism (Scrum Theroy)

Scrum in founded on empirical process control theroy, or empricism.

Empricism asserts that konwledge comes from experience and making decisions based on what is
know.

Mean working in fact-based, exeperience-based, and evidence-based manner.

Scrum implement an empiracal process where progress is base on observation of reality, not fictious
plan.

Scrum also great emphasis on mind-set and cultural shift to achieve business and organizational
Agility.

Three Pillars :

 Transparency (We all know what is going on)

This mean presenting the facts as is. All people involved-the customer, the CEO, individual
contributors are transparent in their day-to-day dealings with others.
They all trust each other, and they have the courage to keep each other abreast of good
news as well as bad news.
Everyone strives and collectively collaborates for the common organizational objective, and
no one has hidden agenda.
 Inspection (Check your work as you do it)
In this context is not an inspection by an inspector or an auditor but an inspection by every-
one on the scrum Team.
The inspection can be done for the product, process, people, aspect, practices, and
continuous improvement.
For exemple, the team openly and transparently shows the product at the end of each Sprint
to the customer in order to gather valuable feedback. If the customer change the
requirements during inspection, the team does not complain but rather adapts by using this
as an opportunity to collaborate with the customer to clarify the requirements and test out
the new hypotesis.
 Adaptation (Ok to change tactical direction)
In this context is about continuous improvement, the ability to adapt based on the results of
the inspection. Everyone in the organization must ask this question regulary.
Are we better off then Yesterday ? For profit-based organizations, the value is represented in
terms of profit.
The adaptation should eventually realy back to one of the reasons for adapting Agil.
For exemple, faster time to market, increased return on investment through value-based
delivery, reduced total cost ownership through enhanced software quality, and improved
customer and employee satisfation.
Scrum Values

 Courage
Scrum Team members have courgae to do the right thing and work tough problems.
 Focus
Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
 Commitment
People personally commit achieving the goals of the Scrum Team.
 Respect
Scrum Team members respect each other to be capable, independent people.
 Opennes
The Scrum Team and its stakeholders agree to be open about all the work and the challenge
with performing the work.

Roles

There are three core roles in Scrum that are ultimately responsible for meeting the project
objectives.

No role has autority over the others.

 The Product Owner

Is the person responsible for maximizing business value for the project. He is responsible for
articulating customer requirements and maintaining business justification for the project.
 The Scrum Master
Is the facilator who ensures that the Scrum Team is provided with an environment conducive
to completing the product’s development successfully.
 The Scrum Team
Is a group or team of people who are responsible for understanding the business
requirements specified by the Product Owner, estimating User Stories, and final creation of
the project deliverables.
Events 

Prescribed events are used in Scrum to create regularity and to minimaze the need for meetings not
defined in Scrum.

All events are time-boxed events, such that every event has a maximum duration. Once the sprint
begins, its duration is fixed and cannot be shortened or lengthened.

 Sprint Planning
This is the event that kick starts each Sprint and is where the Product Owner and
Development Team discuss which Product Backlog Items (PBI’s) wil be included in Sprint.
While the product owner has the right to prioritise each PBI for potential inclusion in the
Sprint, the development team are encouraged to respond, raise issues and push back where
necessary.
The development team then forecasts how many PBI’s they can deliver in the Sprint, given
their knowledge of velocity, ressources and any factors which could influence the time and
resources they have available.
The outcome of the Sprint Planning Meeting is to get a Sprint Goal and Sprint Backlog that
everyone agrees is realistic and achievable.
 Daily Scrum
The Daily Scrum is time-boxed to 15 minutes. Standing up is not compulsory.
The Daily Scrum is an opportunity for the development team to check in, assess progress
towards achieving the Sprint Goal and to review and plan their activities for the next 24
hours.
 Sprint Review
Take place at the end of the Sprint.
Usually takes place on the last day of the Sprint and allows you the opportunity to show the
« done » increment to stakeholders (Customer, management and anyone else considred
relevent and interested).
As well ad demonstrating the working features produced during the Sprint, you’re also after
useful feddback that can be incorporated the Product Backlog that may help guide the work
for the future Sprint.
 Sprint Retrospective
The final meeting in the sprint is the Sprint Retrospective.
This is when the Scrum Team reviews what could be improved for future Sprints and how
they should do it. The ethos of dictates that no matter how good the Scrum Team is, there
will always be opportunity to improve and the Sprint Retropective gives the team a
dedicated time in which to identify, discuss and plan this.
The whole Scrum Team should take part.
 Sprint
The Sprint is an event in itself that contains all the work and all the other events that happen
during the time boxed period of development.
Artifacts

The Scrum framework describe three artifacts :

 The Product Backlog

The product backlog is an ordered list of eveything that is know to be needed in the product.
It is the single source of requirements for any changes to be made to the product. The
Product Owner is responsible for the Product Backlog, including its content, availability, and
ordering.
It constantly changes to identify what product needs to be appropriate, competitive, and
useful. If a product exists, its product backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements and fixes that
constitue the changes to be made to the product in futures releases.
Product backlog items have the attributes of a description, order, estimate, and value (Often
includ test descriptions that will prove its completeness when « Done ».
Multiple Scrum Teams often work together on the same product. One Product Backlog is
used to describe the upcoming work on the product. A product backlog attribute that groups
items may then be employed.
Product Backlog refinement is the act of adding detail, estimates and order to items. This is
an ongoing process in which the Product Owner and Development Team collaborate on the
details. During Product Backlog refinement, items are reviewed and revised. The scrum team
decides how and when refinement is done. Refinement usually consome no more than 10%
of the capacity of the development team. However Product Backlog Items can be updated at
any time by the Product Owner or at the Product Owner’s discretion.
Higher Product backlog Items are usually clearer and more detailed than lower irdered ones.
Product Backlog items that can be « Done » by th Development Team within one sprint are
deemed « Ready » for selection in a sprint planning.
The Development Team is responsible for all estimates. The product owner may influence
the development team by helping it understand and select trade-offs, but the people who
will perform the work make the final estimate.

- Monitoring Progress Toward Goal

At any point in time, the total work remaining to reach a goal can be summed. The Product
Owner tracks this total work remaining at least every Sprint Review. The Product Owner
compares this amount with work remaining at previous Sprint Review to assess progress
toward completing projected work by the desired time for the goal. This information is made
transparent to all stakeholders.

Various project practices upon trending have been used to forecast progress, like burn-chart,
burn-ups or cumulative flows. These have proven useful. However, these do not replace the
importance of empiricism. In complex environments, what will happen is unknown. Only
what has already happened may be used for forward-looking decision-making.

 Sprint Backlog
The Sprint Backlog is the set of Product Backlog Items selected for the sprint, plus a plan for
delivering the product increment and realizing the Sprint goal.
It includes at least one high priority process improvement identified in the previous
Retrospective meeting.
 The Sprint Backlog is a plan with enough detail that changes in progress can be understood in
the daily meeting.
The development team modifies the Sprint Backlog throughout the Sprint, and the Sprint
Backlog emerges during the Sprint.
As a new work is required, the development team adds it to the sprint backlog. As work is
performed or completed, the estimated remaining work is updated. When elements of the
plan are deemed unecessary, they are removed.
Only the Development Team can change its Sprint Backlog during Sprint. The Sprint Backlog
is highly visible, real-time picture of the work that the Development Team plans to
accomplish during the Sprint, and it belongs solely to the Development Team.
- Monotoring Sprint Process

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be
summed. The Development Team tracks this total work remaining at least for every Daily
Scrum to project the likelihood of achieving the Sprint Goal. By Tracking the remaining work
throughout the Sprint, the Development Team can manage its progress.

 Increment
Is the sum of all the Product Backlog Items completed during a Sprint and the value of the
increment of all previous Sprint.
At the end of a Sprint, the new Increment must be « Done », which means it must be useable
condition and meet the Scrum Team’s definition of « Done ».
An Increment is a body of inspectable, done work that supports empiricism at the end of the
Sprint.
The Increment is a step toward a vision goal. The increment must be useable condition
regardless of whether the Product Owner decides to release it.
Why Use Scrum

 Adaptability
Empirical process control and iterative delivery make projects adaptable and open to
incorporating change.
 Transparency
All information radiators like Scrupboard and Sprint Burdown chart are shared, leading to an
open work environement
 Continuous Feedback
Is provided through the Conduct Daily Standup, and Demonstrate and Validate Sprint
processes
 Continuous Improvement
The deliverables are improved progressively Sprint by Sprint, through the Groom Prioritized
Product Backlog process
 Conitnuous Delivery of value
Iterative processes enable the continuous delivery of value through the Ship Deliverables
process as frequently as the customer requires.
 Sustainable Pace
Scrum processes are designed such that the people involved can work at a sustainable pace
that they can, in theory, continue indefinitely.
 Early Delivery of High Value
The Create Prioritized Product Backlog process ensures that the highest value requirements
of the customer are satisfied first
 Efficient Development Process
Time-boxing and minimazing non-essential work leads to higher efficiency levels
 Motivation
The Conduct Daily Standup and Retrospect Sprint processes lead to greater levels of
motivation among employees
 Faster Problem Resolution
Collaboration and colocation of cross-functional teams lead to faster problem solving
 Effective Deliverables
The Create Prioritized Product Backlog process ad regular reviews after creating deliverables
ensures effective deliverables to the customer.
 Customer Centric
Emphasis on business value and having a collaborative approch to stakeholders ensures a
customer-oriented framework.
 High Trust Environement
Conduct Daily Standup and Retropect Sprint process promote transparency and
collaboration, leading to a high trust work envrionment ensuring low friction among
employees
  Collective Ownership
The Commit User Stories process allows team members to take ownership of the project and
their work leading to better quality.
 High Velocity
A collaborative framework enables highly skilled cross-functional teams to achieve their full
potential and high velocity.
 Innovative Environement
The Retropect Sprint and Retropect Project processes create an environment of
introspection, learning, and adaptability leading to an innovative and creative work
environment.

Scrum Principales

Scrum principales are the core guideliness for applying the scrum framework and should mandatory
be used in all Scrum projects.

1. Empircal Process Control

2. Self-Organization
3. Collaboration
4. Value-based Priorization
5. Time-Boxing
6. Iterative Development

Scrum Aspects

The Scrum Aspects must be adressed and manaed throughout a Scrum Project.

1. Organization
Scrum roles fall into two broad categories
a. Core Roles
Core Roles are those roles which are mandatorily required for producing the
projetc’s product or service.
i. The Prodcut Owner
ii. The Scrum Master
iii. The Scrum Team
b. Non Core Role
i. Stakeholders
ii. Scrum Guidance Body
iii. Vendors
2. Business Justifcation
Business Justification in Scrum is based on the concept of Value-driven Delivery.
Considering this uncertainty of achieving sucess, Scrum attempts to start deliering results as
early in the project as possible.
 Scrum’s adaptability allows the project’s objectives and processes to change if its business
justification changes.
The Product Owner is primarily responsible for business justification, other team members
contrinute sgnificantly.
3. Quality
In Scrum, quality is defined as the ability of the completed product or deliverables to meet
the Acceptance Criteria and achieve the business value expected by the customer.
4. Change
5. Risk
Risk that are likely to have a positive impact on the project are referred to as opportunities,
whereas threats are risk that could affect the project in a negative manner.
Product Owner
The product owner represents the interests of the stakholders community to the Scrum Team.

The product owner is responsible for ensuring clear communication of product or service
functionality requirements to the Scrum Team, defining Acceptance Criteria and ensuring those
criteria are met.

In other words, the product owner is responsible for ensuring that the Scrum Team delivers value.

The Product Owner must always maintain a dual view.

The Product Owner must understand and support the needs and interests of all stakeholders, while
also understanding the needs and working of the Scrum Team.

Because the Product Owner must understand the needs and priorities of the stakeholders, including
customer and users, this role is commonly referred to as the voice of the customer.

Product Owner Responsibilities

 Create Project Vision
o Defines the project Vision
o Helps create the project Charter and Project Budget
 Identify Scrum Master and Stakeholders
o Help finalize Scrum Master for the project
o Identifies Stakholders
 Form Scrum Team
o Helps determine Scrum Team members
o Helps develop a Collaboration Plan
o Helps develop the Team Building Plan with Scrum Master
 Develop Epics
o Create Epics and Personas
 Create Prioritized Product Backlog
o Prioritizes Prioritized Product Backlog items
o Defines Done Criteria
 Conduct Release Planning
o Creates Release Planning Schedule
o Helps determine Lenght of Sprint
 Create User Stories
o Helps create User Stories
o Defines Acceptance Criteria for every User Story
 Estimate User Stories
o Clarifies User Stories
 Commit User Stories
o Works with Scrum Team to commit User Stories
 Identify Tasks
o Explains user Stories to the Scrum Team while creating the Task List
 Estimate Tasks
o Provides guidance and clarification to the Scrum Team in estimating effort for tasks
 Create Sprint Backlog
 o Clarifies requirements to the Scrum Team while creating the Sprint Backlog
 Create Deliverables
o Clarifies business requirements to the Scrum Team
 Groom Prioritized Product Backlog
o Grooms the Prioritized Product Backlog
 Demonstrate and validate Sprints
o Accept/Rejects Deliverables
o Provides necessary feedback to Scrum Master and Scrum Teams
o Updates Release Plan and Prioritized Product Backlog
 Ship Deliverables
o Helps deploy Product Releases and coordinates this with the customer
 Restropect Project
o Participates in Retrospective Sprint Meeting
 Determining the project’s initial overall requirements and kicking off project activities ; this
may involve interaction with the Program Product Owner and the Portfolio Product Owner to
ensure that the project aligns with direction provided by senior management
 Representing users of the product or service with thorough understanding of the user
community
 Securing the initial and ongoing financial resources for the project
 Focusing on value creation and overall Return on Investment (ROI)
 Assessing the viability and ensuring the delivery of the product or service
Initiate
8.1 Create Project Vision

8.2 Identify Scrum Master and Stakeholder(s)

8.3 Form Scrum Team

8.4 Develop Epic(s)

8.5 Create Prioritized Product Backlog

8.6 Conduct Release Planning

Plan and Estimate

9.1 Create User Stories

9.2 Estimate User Stories

9.3 Commit User Stories

9.4 Identify Tasks

9.5 Estimate Tasks

9.6 Create Sprint Backlog

Implement
10.1 Create Deliverables

10.3 Groom Prioritized Product Backlog

Review and Retrospect

11.1 Demonstrate and Validate Sprints

Release
12.1 Ship Deliverables

12.2 Retrospect Project