Pathway To Scrum Master Certification

1. Scrum Overview
Jaladhi Bhatt

2. Birth of Scrum
• Term adopted from rugby football: a
scrum is way to restart the game after
an interruption, where the forward
of each side come together in a tight
formation and struggle to gain
possession of the ball when it is
tossed among them.

3. Impediments of Project Execution
Organizing Team
Changes in Scope
Unclear Rules

4. Where needs to apply Scrum ?
Predictable Chaotic Anarchy
It is typical to adopt the
defined (theoretical)
modeling approach when
underlying mechanism by
which process operates are
reasonably well understood
When the process is too
complicated for the
defined approach, the
empirical approach is the
appropriate choice
Unknown
Known Unknown
Requirement
Technology

5. Potentially Shippable
Product Increment
What is Scrum ?
Product Backlog Sprint Planning Sprint Backlog
2 – 4
Week
Sprint
Daily Scrum
Meeting3

6. Scrum Detailing
DEVELOP
DEPLOY
RELEASE
Feedback, Review & Accept
STORY - 1
Develop, Integrate, Test
INITIATE
Define Requirements &
Priorities
CONTINUOUS VISIBILITY
REVISE
Clients,
Developers
& Users
INTEGRATE
& TEST
INTEGRATE
& TEST

7. Project Execution Results
Running(&Tested)Features
Time
Technical
Debt
WEAK “done”

8. What is Sprint ?
Submit An Idea Help Realize an
Idea..!!
Exhibit Your
Collaboration…!!

9. Why Agility Practice
In
Software Development ?
Individual and Interaction V/s. Processes & Tools
Working Software V/s. Comprehensive Documentation
Customer Collaboration V/s. Contract Negotiation
Responding to Change V/s. Following Plan

10. 12 Agile Principal’s
1. Our Highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development, Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preferences to the shorter timescale.
4. Business people and developers must work together daily through the project.
5. Build project around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a Constance pace indefinitely.
7. Working software is primary measure of progress.
8. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity - the art of maximizing the amount of work node done - is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective , then tunes and adjusts its behavior accordingly.

11. Scrum Framework Artifacts
1. Product Backlog Refinements(PBS)
• What: PBS is the process through which product backlog items are reviewed by the
Scrum team and revised, providing more detail and ensuring that there is greater
clarity in the requirements for that item: acceptance criteria, diagrams (architectural,
process flow, UI designs, etc..) example data, test cases
• Who: All members of the Scrum team should be involved in product backlog
refinements. This measures that the whole team understands what is required from
each product backlog item that may be taken into a sprint.
• When: PBS should be an ongoing process. However, some teams find it useful to
have a planned mid-sprint session that allows for product backlog items that are
candidates for the next sprint to be discussed

12. Scrum Framework Artifacts
1. Product Backlog Refinements(PBS)
• Keep the Product Backlog in order
• Remove or demote Product Backlog Items (PBI) that no longer seem important
• Add or Promote Product Backlog items (PBI) that raise or become more important.
• Split Product Backlog Items (PBI) into smaller items
• Merge Product Backlog Items (PBI) into larger items
• Estimate Product Backlog

13. Scrum Framework Artifacts
2. SPRINT (ITERATION) PLANNING
i. Selection – What can be done
• PO & Development Team discuss PBI
• Development Team determines how much work can be done according to
the historical data for velocity
• NO ONE can push more work to the Development Team
• Focus on WHAT
2 hours/
Week
Time Box

14. Scrum Framework Artifacts
2. SPRINT (ITERATION) PLANNING
ii. Planning – How to get it done?
• Developing Team decides how to produce the committed increments
according to the DoD
• JIT (Just IN Time) Design is to conduct Decompose larger items to smaller
ones; in the format of Features or Tasks
• Focus on HOW
15
Minutes
Time Box

15. Scrum Framework Artifacts
3. DAILY SCRUM / STAND-UP
• Daily, Stand-up; Same time same place
• BROADCAST individual updates to everyone
• Not a status check-up meeting; team member making COMMITMENTS in front of peers
• NO PROBLEM SOLVING during the meeting
• Everyone is invited but ONY SCRUM ROLES can speak
• 3 Questions to be answered
• What did I get DONE yesterday?
• What will I get DONE today?
• Any impediments blocking me?
15
Minutes
Time Box

16. Scrum Framework Artifacts
4. SPRINT REVIEW
• Team presents what is accomplished (DONE) during the sprint
• It typically take the form of a demo of new features or underlying
architecture
• Informal : 2 – hour preparation time rule – NO SLIDES
• All Stakeholders and interested parties are invited
1 Hour/
Week
Time Box

17. Scrum Framework Artifacts
5. SPRINT RETROSPECTIVE
• Continues improvements
• Every Sprint; right after the Sprint Review
• Whole team participates
• Other interested parties are welcome but only team speaks.
• 3-Question Format:
• What shall we start doing ?
• What shall we stop doing ?
• What shall we keep doing ?
1 Hour/
Week
Time Box

18. Scrum Framework Artifacts
THE DEVELOPMENT TEAM
CHARACTERISTICS
• 5-9 People
• Cross Functional
• Business Analysis
• UX/UE
• Programmer
• Tester
• Deployment
• Self-Managed
• No Management Title
• Team Accountability
• Team takes most of the project management Task
MISSION
• Delivery Product Increment
• Managed Spring Backlog
• Track Progress
• Decide the best way to work
• Collaborated as a Team
• Make continuous self-improvements

19. Scrum Framework Artifacts
PRODUCT OWNER
CHARACTERISTICS
• One person playing the role
• Authorized to make decisions
• Drives product success
• Represents project to the stakeholders
• Represents stakeholders to the project
• Collaborates with everyone
MISSION
• Creates Product Vision
• Defines the feature of the product
• Responsible for ROI (Return of Investments)
• Prioritize feature per market value
• Adjust Features/ priority according to the
market feedback
• Ensure the readiness of sprint input
• Accept / Rejects work result

20. Scrum Framework Artifacts
SCRUM MASTER
CHARACTERISTICS
• Represents team to the management
• Represents management to the team
• No Management Title
• Authorized “sheep-dog”
• Functions as a coach rather than being a
player
• Change Agent
• Listen rather than tell
• A servant Leader
MISSION
• Responsible for enacting Scrum values and
principles
• Remove impediments
• Serves the Product Owner and the team
• Protect the team
• Facilitates team collaboration / productivity

21. Scrum Artifacts
1. PRODUCT BACKLOG
• A DYNAMIC list of functionalities
the product MIGHT include
• Other work providing value to the
users
• A health Product Backlog must be
DEEP:
• Detailed Appropriately
• Estimated
• Emerged
• Prioritized/ Ordered
• Open to all but ultimately groomed
by the Product Owner
• Focus on WHAT brings the biggest
value
2. SPRINT BACKLOG
• A Subset of Product Backlog – PBI’s
team believes fit into one sprint
• Product Backlog items (PBI) are
broken down into smaller pieces
• Technical tasks, including JIT (Just
In Time) design, are also included
• Focus on HOW the team gets the
work done and deliver the value in
one sprint
• Emergent – Sprint Backlog Items
(SBI) can be added, edited or deleted
by the team.
• The development team owns this
asset
3. INCREMENT
• The sum of all the PBIs completed
during a Sprint and ALL PREVIOUS
Sprint
• Potentially shippable and meet the
Definition of Done
• Must be in useable condition
regardless whether or not PO decides
to release it.
• Measurement of Burn-down chart
and Task board.

22. 5 Core Values
SPRINT
• All work need to be DONE
deliver working software every
sprint
• Is NOT a mini-waterfall
• Sprint length DOES NOT
CHANGE
• NOT REQUIREMENT
CHANGE inside one Sprint
• Cancelling a sprint – rarely
happens
1 -4
Weeks
Time Box

23. Agile Requirement Management & User Story
• What is User Story?
• Card
• Conversation
• Confirmation
As a [User Role],
I want to [accomplish a result],
So that [I can get some business value].
• Independent
• Negotiable
• Valued
• Estimated
• Sized Appropriately
• Testable• Vertical Slices
• A Small PSPI* instead of
task
• Definition of DONE
• Exit Criteria f how PO accepts work from the
Development Team
• Definition of Ready
• Entry Criteria of when the work is ready for the
Development Team to commit
• *PSPI – Potentially Shippable Product Increment

24. Acceptance Criteria & Backlog Refinement
• A very important and Common element in DoR
• Define WHAT, not HOW – Different from Functional Tests
• Given / When / Then Format
• Given: [ a pre-condition]
• When: [ user inputs]
• Then: [user gets expected results]
• Useful tool during Product Backlog Refinements
Write AC
EPIC
EPIC
EPIC
Theme
EPIC
EPIC
Story
Write AC

25. Test Driven Work
• Create tests, then create the work to pass the tests
• Acceptance Test Driven Development
• Test Driven Development
• Test provide a safety net for future work
• Test imply and drive design – Testing is a design activity

26. Test Driven Work

27. Relative Estimation
• Absolute estimates: a precise
measurement with a ‘unit’, e.g.
KG, KM, Hours, etc..
• Relative estimates: a
comparison(multiplier) between two
items, or grouping of items with
equivalent difficult
In Agile, relative estimation is a distinct flavor because:
• It avoids seeking unnecessary prevision: estimate is never precise
• Estimates differs from commitments: when producing a product, the effort needed has nothing to do with the
time spent on it
• It avoids the “evil undone work” : 50% of planned time spent doesn’t lead to 50% completion – we track
‘Done’ only.
• It helps to find the appropriate granularity when breaking down the work : the more granular the items are the
easier to estimate

28. Agile Planning & Tracking
• Release level planning & Tracking
• Who/What/When:
• Product Owner & Team/Product backlog refinement activity/
decides when to release what
• How:
• (Re)estimates the entire Product Backlog
• Find the historical date for VELOCITY
• # of sprints needed = Product backlog size / velocity
• Tool / Technology
• Feature Burn-up Chart
• Tracking:
• Release content and priority will be adjusted EVERY SPRINT
according to the market feedback and team velocity

29. Agile Planning & Tracking
• Sprint Level Planning & Tracking
• Tool / Technology
• Planning Poker
• Tracking
• Sprint backlog will be adjusted EVERYDAY according to the
team work result, and their impediments/ dependencies
identified during the sprint
• Daily Planning & Tracking
• Daily scrum is a daily re-planning activity
• Team member track their work in REAL TIME by updating
their work on the task board.