Covers SCRUM Artifacts topic in detail along with necessary linked topics understanding. Below are SCRUM Artifacts covered in this presentation: Product Backlog Sprint Backlog Increment / Product Increment

1. SCRUM ARTIFACTS
What are they and why they are important
Presentation by Gul Zaman Ilyas

2. About Presenter
Email: zamanilyas@hotmail.com | Ph. #: (+92) 323 141 6914
Professional Summary:
A Certified Scrum Master & MCSD possessing almost 18+ Total Years of
Professional IT Work Experience & almost 10 Years of Project Management
related experience.
Overall possessing experience in Entrepreneur-ship, IT Operations, IT
Infrastructure, Software Architecture & Development, IT Consultancy, Cloud
Platforms, Virtualization, Networks and much more.
Tools Stack:
Communication, Training, Networks, IT Operations, IT Infrastructure, Microsoft
Technologies, Linux, Cloud (Public, Private & Hybrid), Virtualization, AWS, Azure

3. SCRUM Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for
inspection and adaptation.
Artifacts defined by Scrum are specifically designed to maximize transparency of key
information so that everybody has the same understanding of the artifact.
The Scrum Artifacts are:
– Product Backlog
– Sprint Backlog
– Increment / Product Increment

4. Product Backlog – What is a Product
■ What constitutes a product?
– IVAN-X, MS Office vs MS Excel, Word, etc.
■ Simple definition usually works…
– A product is something of value that a customer would be willing to pay for and
something “we” would be willing to “package” up and sell
■ Component - Teams bump up against this simple definition
– Customer buying the component?
– Component going into multiple products?
■ Leads to a rabbit hole!

5. Product Backlog – What is a Product?
■ Large Products utilize Hierarchical Product Backlogs
■ Multiple, interchangeable teams can utilize one Product Backlog
■ Multiple, non-interchangeable teams need to have a team-specific view of the single
Product Backlog

6. Product Backlog – What is a Product?
■ Case 1 on the left side
of image where Multiple
Products best handled
by one or more teams
working exclusively on a
single product backlog
■ Case 2 on the right side
of image where
Occasionally, not ideal,
one team works on
multiple Product
Backlogs

7. ■ The Product Backlog
– Is a prioritized list of desired product functionality (artifacts)
– Centralized & Shared understanding of what to build and its build order
– Is highly visible to all Scrum participants
– Exists for products being built, enhanced, or supported
– The Product Backlog is the master list of all functionalities desired in the product
– It is NOT necessary to start a project with a lengthy, upfront effort to document all
requirements.
– Product backlog items can be
■ Technical tasks
– Bugs, Enhancements, Issues
– E.g. "Refactor the Login class to throw an exception"
■ User-centric
– User Stories
– E.g. “Subscription should be charged through Direct Carrier Billing (DCB)"
– XP User Stories is a good approach to fill the Product Backlog
– Product Owner writes and prioritize the product backlog
– Scrum master can update it along the sprints
7
Scrum Artifacts

8. 8
Estimates have been
developed by the
developers but it is
understood that they are
very imprecise and are
useful only for rough
assignments of tasks into
the various sprints.
- Point Estimation
- Time Estimation
Sample Product Backlog

9. Product Backlog
https://www.youtube.com/watch?v=NUqaIcbhdLU

10. Product Backlog Items
■ Product Backlog consists of backlog items,
called PBIs, backlog items, or just items
■ Most PBIs:
– Are features/functionalities that will
have tangible value to the user or
customer
– Often are written as User Stories (but
Scrum does not dictate a format)
■ Examples of PBIs include:
– Features
– Change
– Defects
– Technical Work
– Knowledge Acquisition (proof of concept)

11. PBI Examples
PBI Type Example
Feature As a customer service representative I want to create a ticket for a
customer support issue so that I can record and manager a
customers request for support.
Change As a customer service representative I want the default ordering of
search results to be by last name instead of ticket number so that
it’s easier to find a support ticket.
Defect Fix defect #256 in the defect-tracking system so that special
characters in search terms wont make customer searches crash.
Technical Improvement Move to the latest version of the Oracle DBMS
Knowledge Acquisition Create a prototype or proof of concept of 2 architectures and run
three tests to determine which would be a better approach for our
product.

12. Good Product Backlog Characteristics
DEEP acronym coined by Roman Pichler (2010) & Mike Cohn (MountainGoatSoftware)
■ Detailed Appropriately
■ Emergent
■ Estimated
■ Prioritized

13. Product Backlog Characteristic – Detailed Appropriately
■ Not all PBIs are at the same level of detail at
the same time
■ PBIs being prepared to work on should be
small, very detailed, and near the top of the
prioritized list
■ Other PBIs are lower in the list, larger in
size, and less detail
■ Larger PBIs, EPICs, are decomposed into
sprint-ready items in a just-in-time fashion

14. Product Backlog Characteristic - Emergent
■ While a product is being built, enhanced, or supported, its backlog is never complete
or frozen
■ Product Backlog is continuously being updated based on a stream of economically
viable information
■ Therefore, the Product Backlog’s structure is fluid needing rebalancing and
prioritizing based on new information

15. Product Backlog Characteristic - Estimated
■ Each PBI has a size estimate associated with it
■ Product Owner uses the estimate as one input to
prioritization
■ Large PBIs near the top of the list indicate
refinement is necessary
■ Most PBIs are estimated in either story points or
ideal days (See Chapter 7 for details)
■ Estimates should be reasonably accurate without
being overly precise
■ Smaller, near top of the list PBIs will have smaller,
more accurate size estimates
■ Epics, larger PBIs, are more difficult to estimate
accurately so some teams use T-shirt size
estimates (L, XL, XXL, etc.)

16. Product Backlog Characteristic - Prioritized
■ Not necessary to actually prioritize items
near bottom of the list
■ Useful to prioritize PBIs that are
candidates for the next few sprints or to a
first release
■ Too much time focus on the future is to
be avoided
■ Of course changes can shuffle PBIs

17. Product Backlog Grooming
■ Product Owner leads grooming & is the final
decision maker
■ Input from stakeholders, ScrumMaster, Dev. Team
■ Dev. Team should allocate up to 10% of its time
each sprint for grooming
■ Grooming - Proactively manage, organize, and
administer the Product Backlog to accomplish DEEP
characteristics
■ Grooming activities:
– Creating & Refining PBIs
– Estimating PBIs
– Prioritizing PBIs
■ Scrum framework does not specify when grooming should
take place
■ Waterfall development tries to capture detailed
requirements up front so little or no grooming is scheduled
(yet it always occurs!)
■ Scrum expects an uncertain environment so team must be
prepared to constantly inspect and adapt
■ Initial grooming occurs as part of the release-planning
activity
■ On-going grooming can occur once-a-sprint, every week, or
even daily

18. Product Backlog Grooming
■ Grooming the backlog should ensure that
PBIs at the top of it are ready to move into a
sprint
■ Some teams establish a definition for Ready
similar to Done to help formalize grooming
■ Example of a Ready Checklist

19. Question
In product refinement, the first case is consider as ______ for long-term release
planning to be done.
A. Existing product
B. Refined product
C. New product
D. None of these

20. Question
In product refinement, the first case is consider as ______ for long-term release
planning to be done.
A. Existing product
B. Refined product
C. New product
D. None of these
Correct Answer: C

21. Product Backlog Flow Management
■ Product Backlog is crucial
to achieving fast, flexible
value-delivery in the face of
uncertainty which always
exists in projects
■ Release planning can be
visualized as a line through
the product backlog
■ Specific release can be
partitioned into 2 more
lines – must have and nice
to have
■ Won’t have is below the
release cut-off line

22. Question
For many SCRUM teams is most workable to have __________ worth of user stories
ready to go.
A. 2 to 3 Sprints
B. 3 to 5 Sprints
C. 5 to 7 Sprints
D. None of these

23. Question
For many SCRUM teams is most workable to have __________ worth of user stories
ready to go.
A. 2 to 3 Sprints
B. 3 to 5 Sprints
C. 5 to 7 Sprints
D. None of these
Correct Answer: A

24. Product Backlog Flow Management
■ For a Sprint, the Product Backlog can be
viewed as a pipeline of requirements that
are flowing into the Sprint
■ A problem arises if there is a mismatch or
unevenness between inflow and outflow
in this pipeline
– Too slow – pipeline could run dry
– Too fast – may cause rework/throw
away as more is learned
■ Rule of thumb for many teams is to have
2 to 3 sprint’s worth of user stories ready
to go

25. Summary
■ Crucial Role of the Product Backlog in achieving fast, flexible, value-delivery in the presence
of uncertainty
■ Structural and Process issues surrounding the Product Backlog
– Types of items
– How to groom
■ Which and how many Product Backlogs

26. Sprints
■ Scrum organizes work in iterations or
cycles, called Sprints, of up to a
calendar month
■ Sprint key characteristics:
– Timeboxed
– Short and consistent duration
– Goal should not be altered once
started
– Must reach the end-state
specified by the team’s definition
of done

27. ■ The Sprint Backlog
– The list of tasks that the Scrum team is committing that they will complete in the current
sprint.
– Items on the sprint backlog are drawn from the Product Backlog, and Detailed into
smaller list of things needed to be done
– Selected based on the priority of in the product backlog
– Due by next sprint !!
■ Sample Sprint Backlog
– As a user, I want to reserve a hotel room
■ Add hotel table to the database – 1 hr
■ Write Ajax code to display reservation – 4 hrs
■ Write code to enter reservation in the database – 4 hrs
– As a user, I want to cancel a reservation
■ Display the user’s current reservations – 4 hrs
■ Add a cancel button next to each reservation – 1 hr
27
Scrum Artifacts

28. Some facts about Sprint Backlog
1) The Sprint Backlog is created anew for each Sprint
2) The Sprint Backlog is created by The Team Itself
3) Only tasks that The Team agrees to commit to is added to the sprint.
4) Tasks are broken down into manageable pieces and given estimates.
5) Team members signs up for tasks.
6) Tasks can be added or removed during the sprint.
Scrum Artifacts – Sprint Backlog

29. Sprint Backlog / Sprint Task Board
https://www.youtube.com/watch?v=Ti2g66b7MUo

30. 30
Sample Sprint Backlog

31. Questions
_______ are created during second half of the sprint planning meeting
A. Sprint
B. Task
C. User stories
D. Sprint backlog

32. Questions
_______ are created during second half of the sprint planning meeting
A. Sprint
B. Task
C. User stories
D. Sprint backlog
Correct Answer: D

33. Questions
During sprint, the___________ list are identified and used to list out task by scrum
team.
A. Scrum product
B. Sprint review
C. Sprint backlog
D. Sprint retrospective

34. Questions
During sprint, the___________ list are identified and used to list out task by scrum
team.
A. Scrum product
B. Sprint review
C. Sprint backlog
D. Sprint retrospective
Correct Answer: C

35. Questions
______ are created in first half of the sprint planning meeting according to scrum
master
A. Sprint backlog
B. Scrum
C. Backlog
D. Sprint Goal

36. Questions
______ are created in first half of the sprint planning meeting according to scrum
master
A. Sprint backlog
B. Scrum
C. Backlog
D. Sprint Goal
Correct Answer: D

37. Definition of Done
■ Definition of Done (applies to the product increment) can
evolve over time as organizational impediments or
limitations may necessitate
– Earlier sprints may have a definition of Done that is
somewhat different than later sprints due to this
– Leaving an activity out of a sprint (such as
performance testing) could have a backwards ripple
effect when that activity is actually performed
■ Definition of Done versus Acceptance Criteria
– Each product backlog item in a sprint should have a
set of conditions of satisfaction (acceptance criteria)
for the Product Owner
– Acceptance criteria are item specific and in addition to
definition of Done
– Completed or Accepted (not done) are terms used
when Product Backlog items pass their acceptance
criteria

38. Product Increment
The Increment is the sum of all the Product Backlog
items completed during a Sprint and all previous Sprints.
At the end of a Sprint, the new Increment must be
“Done”, which means it must be in usable condition and
meet the Scrum Team’s Definition of “Done”.
Scrum Artifacts
It must be in usable condition regardless of whether the
Product Owner decides to actually release it.

39. Velocity
Velocity, the amount of total work that can completed in a
sprint.
Typically a full time resource on a 2 week sprint has 8 story
points (8 days out of 10 total days so 80% allocation).

40. Product Release
A very high-level plan for multiple Sprints (e.g. three to twelve iteration) is created during the Release
planning. It is a guideline that reflects expectations about which features will be implemented and
when they are completed. It also serves as a base to monitor progress within the project. Releases can
be intermediate deliveries done during the project or the final delivery at the end.
To create a Release Plan the following things have to
be available:
■ A prioritized and estimated Scrum Product Backlog
■ The (estimated) velocity of the Scrum Team
■ Conditions of satisfaction (goals for the schedule,
scope, resources)
■ Depending on the type of project (feature- or date-
driven) the release plan can be created in different
ways:
■ If the project is feature-driven, the sum of all
features within in a release can be divided by the
expected velocity. This will then result in the
number of sprints needed to complete the
requested functionality.

41. Product Release
■ If the project is date-driven we can
simply multiply the velocity by the
number of Sprints and we'll get the
total work that can be completed
within the given timeline.
■ Like the Scrum Product Backlog the
Release plan is not a static plan. It
will change during the whole project
when new knowledge is available
and e.g. entries in the Scrum
Product Backlog are changed and
re-estimated. Therefore the Release
Plan should be revisited and
updated in regular intervals, e.g.
after each Sprint.