Backlog refinement is not a Scrum event, but instead is an ongoing activity during the Sprint required to decompose, describe, estimate, and order backlog items in the Product Backlog. This material is divided into two sections. The first section reviews the basics of backlog refinement, covering various options for conducting the activity. The second section covers tips for maintaining a healthy backlog and potential anti-patterns. This material was presented at Agile New England in July and August 2022 as "101" introduction and "202" advanced sessions.

1. Backlog Refinement
David Hanson
dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/
https://www.slideshare.net/DavidHanson5
July and August 2022

2. 2
Backlog refinement is not a Scrum event, but
instead is an ongoing activity during the Sprint
required to decompose, describe, estimate, and
order backlog items in the Product Backlog.
This material is divided into two sessions. The
first session will review the basics of backlog
refinement, covering various options for
conducting the activity. The second session will
cover tips for maintaining a healthy backlog and
potential anti-patterns.
About the sessions… About my experience…
Wrote my first user story in 2000 using XP.
Refined a story in pairs, then began the work. Our
goal: start-to-finish in a week. We usually failed.
In 2008, applied Scrum, with one line stories.
Discussed the story only briefly when pulling into
the sprint, then in depth when beginning the
work. Just-in-time worked.
By 2013 was applying a definition of ready to user
stories with acceptance in recurring backlog
grooming, prior to sprint planning. So smooth!
Introduction

3. 3
About your experiences…
…and why are you here?

4. 4
 Refinement: Why & How
 Scrum Guide: 2017 vs. 2020
 Options: How & When (4)
 10% Time & Size (2)
 Process Responsibility &
Pattern (3)
 Poker Planning (2)
 Useful Resources
 The “Fourth” Artifact
 Common Backlog Items
 Backlog Grooming Refinement
 Developers’ Viewpoint
 Tips for a Healthy Backlog (5)
 Potential Anti-patterns (7)
 Shu-Ha-Ri
 Story Splitting (5)
 Scaled Backlog Refinement
 Sample Agendas
 Scrum Master Role
 Story Mapping (3)
 Just Enough
Refinement 101 (17) Refinement 202 (14) Appendix (12)
Session 101, Session 202 and Supplemental Material

5. 101

6. 6
To have a steady flow of high value, ready stories
for the team to deliver to the customer
Why? How?
That’s left undefined, for the team, to discover
what works best for them
Backlog Refinement

7. 7
Development team should anticipate spending up
to 10% of their time on refinement
Product Backlog refinement is the act of adding detail,
estimates, and order to items in the Product Backlog. This is an
ongoing process in which the Product Owner and the
Development Team collaborate on the details of Product
Backlog items. During Product Backlog refinement, items are
reviewed and revised. The Scrum Team decides how and when
refinement is done. Refinement usually consumes 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.
2017 2020
Refinement “is an ongoing activity to add details”
During the Sprint:
● The Product Backlog is refined as needed; and,
Product Backlog refinement is the act of breaking down and
further defining Product Backlog items into smaller more
precise items. This is an ongoing activity to add details, such as
a description, order, and size. Attributes often vary with the
domain of work.
Scrum Guide Direction
Backlog Refinement IS an activity during the Sprint event related the Product Backlog artifact.
Backlog Refinement is NOT identified as a Scrum Event.

8. Backlog refinement
variations and activities

9. 9
PO or team members prepare
stories in advance
PO reviews stories with team
for refinement once or twice a
week in recurring meeting
Scrum Guide recommends up
to 4 hours of sprint planning
for 2-week sprint
4 hours is ample time to refine
stories during planning
PO with analyst or SME can
prepare stories in advance
Leverage abbreviated
refinement meeting or sprint
planning for review with team
Backlog Refinement Meeting During Sprint Planning Refinement Specialists
Pro: just-in-time without distractions
Con: might find key story not ready
Pro: less distraction, more expertise
Con: less team, more silo
Pro: most common, familiar approach
Con: distracts team from sprint goal
Refinement Options
PO: Product Owner

10. 10
Once or twice a week for an
hour or two
Preference for end of day
refinement, so team remains
focused on daily goal
In daily Scrum, PO can request
refinement for a ready story
Meet after daily Scrum up to
30 minutes or alternative
dedicated timeslot
Make time between sprints for
refinement (& improvements)
Incorporate feedback from
sprint review just-in-time for
sprint planning
Recurring Meeting Ongoing Daily Between Sprints
Pro: continuous on-demand
Con: distracts from daily goal
Pro: keeps focus during sprint
Con: diverges from Scrum Guide
Pro: develops rhythm
Con: another meeting
When to Refine?
Tip: schedule activity for a Monday and cancel when a holiday, assuming team generally has ample ready backlog

11. 11
What worked? What didn’t work?
What have you tried?

12. 12
New
> Refine <
Ready
To Do
Doing
Done
Product
Refinement
Sprint
Refinement Iteration Refinement Keyword Refinement State
Good; some tools might
leverage these keywords
Better; customizing tool for
purpose
Fair; a clever hack supported
by some tools
Refinement Backlog
Can you achieve the same results with less overhead?
Product Backlog
Best; no extra overhead and
usually out-of-the-box
“Refine” “Estimate”
Ready 5 pts
Not Ready
Ready __ pts
Ready __ pts
Not Ready

13. 13
If 1 of 5 team members has BA
skills, that member could
spend half-time refining
backlog
That’s 10% of the development
team’s time
The team could pull in spikes
and accept ad hoc requests to
support the PO in refining
stories
The team could allocate 10% of
their capacity for this activity
The team might meet daily for
an hour to refine stories,
except on first and last day of
sprint
That’s 10% of the development
team’s time
Business Analyst Spikes and ad hoc requests Refinement Meeting
Final refinement with the full team left
for Sprint Planning
Final refinement already done, Sprint
Planning could be abbreviated
Final refinement with the full team left
for Sprint Planning
No more than 10% of Developers’ time
How might 4 hours per developer per week be spent?
Recommend some blend of all three

14. 14
Smaller Teams Larger Teams
Team Size
How might smaller or larger teams impact backlog refinement?

15. 15
Who is responsible for what?
Who can add
story to
backlog?
Who prioritizes
or rejects new
story?
Who refines
new story?
Who decides if
story ready?
Who signs off on story before development begins?
Product
Manager
Technical
Manager
Clients
Product
Owner
Scrum
Master
Team
Members

16. 16
Product owner (PO)
Not ready stories ordered by priority
1. Pull not ready story from top of backlog
2. PO reviews story and acceptance with team
3. Team asks questions and provides feedback
4. PO refines story and acceptance based on feedback
a. Split by value or effort
b. Add or modify details
c. Reorder by priority or dependency
5. Team estimates story using poker planning
6. If research needed to point story, then spike added
7. If story too large, then team may split story
8. Repeat until timebox reached
Ready stories, not ready stories with spikes, updated order
Development team
Backlog Refinement Meeting:
A Common Pattern
Supplier:
Input:
Process:
Output:
Consumer:

17. 17
Time per story might be 5 to 10 minutes
If more time needed, then story not ready
Recommend simple close enough rules for pointing
If not close enough, then story not estimable; therefore, not ready
Split larger stories, if needed, during refinement
Spikes should be defined with similar rigor to stories, except timeboxed
Remove unnecessary and duplicate stories
Defer lower value or less urgent stories
Refinement Meeting Considerations
It’s about the conversation and a shared understanding

18. 18
Most common Agile estimation technique
Leverages Fibonacci series: 1, 2, 3, 5, 8, 13, 21
Team initially establishes some very simple
benchmark story as 1 pointer
A relative estimation of complexity and effort
Accounts for all the work from ready to done
A 2-pointer is twice as complex as a 1-pointer
Team very quickly “knows” the relative sizes
against the baseline stories
What How
PO reviews story with team
Team asks questions and PO responds
SM asks if ready to estimate
Team members each select a Fibonacci number
SM asks team members to reveal estimates
SM asks one low and one high to comment why
consider simpler or more complex
PO may provide more information
SM asks team to re-estimate
If team converges then story pointed
Else story not ready
Poker Planning
PO: Product Owner
SM: Scrum Master

19. 19
Why points, not hours?
Why relative effort and complexity?
Why Fibonacci?
Why high and low?
Why converge?
Why benchmark?
Why whole team?
Why not PO and SM?
Why Alternatives
Ideal days instead of story points
Modified Fibonacci: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
Additional cards: 0, ?, ∞, ,
Benchmark: instead of 1 point, try 2 points
Poker Planning
Image: https://en.wikipedia.org/wiki/Fibonacci_number

20. 20
Product Goal Definition of Ready
Backlog Refinement Resources
What other resources might be useful during refinement?
Independent
Negotiable
Valuable
Estimable
Small
Testable

21. 21
Product Backlog and Sprint Backlog both contain
Backlog Items
Analogously:
Sprint contains Planning, Daily Scrum, Review,
Retrospective
Artifact: Backlog Item* Commitment: Definition of Ready*
Must commit to meet Definition of Ready before
pulling into Sprint Backlog from Product Backlog
Analogously:
Increment Commitment: Definition of Done
The Fourth Artifact
*Not an official Scrum artifact or commitment, but I would argue that the individual element warrants consideration
Independent
Negotiable
Valuable
Estimable
Small
Testable
As a <user>,
I need <function>,
so that <purpose>.

22. 22
Initiative
Epic
Feature
Story
Spike
Defect
Impediment
Kaizen
Activity (Jira: Task)
Story
Spike
Defect
Kaizen
Story
Spike
Defect
Task (Jira: Sub-task)
Impediment
Activity (Jira: Task)
Product Backlog Backlog Refinement Meeting Sprint Backlog
Epics, Kaizens and Tasks are generally
NOT discussed in Backlog Refinement
Tasks may be defined during 2nd half of
Sprint Planning or during Sprint itself
Lack consensus on definition and
scope of Feature relative to Epic
Common Backlog Items
Tools and company implementation may dictate the types of backlog items available

23. 23
verb: groom; 3rd person present: grooms; past tense: groomed; past
participle: groomed; gerund or present participle: grooming
1. a. brush and clean the coat of (a horse, dog, or other animal).
b. (of an animal) clean the fur or skin of.
c. give a neat and tidy appearance to (someone).
d. look after (a lawn, ski slope, or other surface).
2. a. prepare or train (someone) for a particular purpose or activity.
b. (of a pedophile) prepare (a child) for a meeting, especially via an
internet chat room, with the intention of committing a sexual offense.
Original term, now considered
non-PC because of recent usage
describing nefarious behaviors
(definition 2b)
Backlog Grooming
Anyone know why this term has gone out of favor?

24. 24
Concluding Questions
Who pretty much follows an approach outlined here?
How’s it working?
What’s not working?
How has your backlog refinement evolved?
Did you come away with any take-aways?
What might you try in your next backlog refinement?
What was most valuable to you?

25. Appendix 101

26. 26
So, team can confidently commit to
completing story within a sprint
So, PO can separate high value, low effort
from low value, high effort
So, PO can identify hidden value and team
identify hidden effort
Why split stories?
Different users
need this and that
for one thing or
another
21
Value Effort

27. 27
Value vs. Effort
User
needs this or that
for something
8
User
needs this
for something
3 User
needs that
for something
5
Value Effort

28. 28
Hidden Value or Effort
User
needs this or that
for something
8
User
needs that
for something
5
Value Effort
User
needs this
for something
5 User
needs this and that
for something else
3

29. 29
Split by acceptance criteria
Split by keywords: and, or, either, with, using, lists
Split by user roles
Split by happy and unhappy paths
Split by workflow*
A More Advanced Technique
Split into tasks and reassemble
Seek simplest set of tasks adding value, then add
incrementally
Some Simple Techniques Vertical, not Horizontal
Do not split horizontally
Do split vertically
Story Splitting Techniques
* Use with caution; don’t want to deliver one step in a workflow if doesn’t deliver value to user
User Interface
Database
Middle Tier
UI Browse
DB Browse
MT Browse
UI Order
DB Order
MT Order
UI Pay
DB Pay
MT Pay

30. 30
Spikes: split off research of architectural design or technical
implementation options
Paths: consider the many paths the user may navigate, both happy
and unhappy, as well as the many options
Interfaces: first a simple interface, then a complex interface; first a
mobile interface, then a web interface
Data: support a subset a data, then an expanding data set; support
correct data, then errant data
Rules: consider the various business rules, starting with simple
rules, and adding complexity
Mountain Goat’s SPIDR Approach to Splitting
https://www.mountaingoatsoftware.com/exclusive/spidr-poster-download

31. 31
PI Planning involves the Scrum team in a form of
backlog refinement
In addition to epics and stories, SAFe recommends
intermediate-sized capabilities and features, as
well as architectural enablers
Product managers, POs and representative SMEs
from ARTs may refine capabilities and features
System architects refine enablers, which can be
epics, capabilities, features, or stories
SAFe Scrum @ Scale
PO Team should meet regularly for scaled backlog
refinement to break down epics into stories,
resolve dependencies, and align stories with
respective teams
Scaled Backlog Refinement
https://www.scaledagileframework.com/features-and-capabilities/
https://www.scaledagileframework.com/enablers/

32. 32
Purpose: Maintain steady flow of high value stories
Activity:
1. Discuss near-term product goals
2. Start with highest priority story not yet pointed
3. Read story description and acceptance criteria
4. Confirm who, what, why and elaborate if needed
5. Confirm acceptance and elaborate if needed
6. If ready, point story using poker planning
7. If not ready, mark not ready
8. If too large, then split story
9. If uncertain, then add spike, if appropriate
10. Reorder priority of story if appropriate
Attendees: Scrum Team, led by PO, facilitated by SM
Backlog Refinement Scaled Backlog Refinement
Purpose: Insure aligned backlogs across team of teams
Activity:
1. Discuss near-term product goals
2. Order epics & stories in backlog to align with goals
3. Align epics or stories with respective team backlogs
4. Identify and resolve stories with cross-team
dependencies (by ordering or splitting)
5. Optional: draft new epics or stories, refine existing
epics or stories, split large stories
Attendees: Product Owner Team, led by Chief Product
Owner, facilitated by Chief Scrum Master
My Most Recent Refinement Meeting Agendas

33. 33
David Hanson
dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/
https://www.slideshare.net/DavidHanson5
17:45
01:47

34. 34
 Refinement: Why & How
 Scrum Guide: 2017 vs. 2020
 Options: How & When (4)
 10% Time & Size (2)
 Process Responsibility &
Pattern (3)
 Poker Planning (2)
 Useful Resources
 The “Fourth” Artifact
 Common Backlog Items
 Backlog Grooming Refinement
 Developers’ Viewpoint
 Tips for a Healthy Backlog (5)
 Potential Anti-patterns (7)
 Shu-Ha-Ri
 Story Splitting (5)
 Scaled Backlog Refinement
 Sample Agendas
 Scrum Master Role
 Story Mapping (3)
 Just Enough
Refinement 101 (17) Refinement 202 (14) Appendix (12)
Session 101, Session 202 and Supplemental Material

35. 202

36. Exercise Preview
Zoom annotation

37. 37
Backlog Refinement:
A Summary from the Developers’ Viewpoint
The product backlog is maintained through product backlog refinement:
§ Refinement is the continuous act of adding detail, estimates, and order to items*.
§ Product Backlog refinement is the responsibility of the Product Owner.
§ The Product Owner may enlist the help of the Developers to refine the Product Backlog.
§ Refinement should not take up more than 10% of the Developers' time.
§ The Developers may create and add new Product Backlog items to assist the Product Owner. The
Product Owner remains accountable and should always be the gatekeeper to the Product Backlog.
§ The higher the order of the Product Backlog item, the more refined it should be.
§ The Product Backlog should contain enough “ready” Product Backlog items for the Developers to pull
into a Sprint Backlog in the next Sprint Planning and that can be “done” to accomplish a Sprint Goal.
§ Product Backlog refinement is an ongoing activity during the Sprint, not an official Scrum event.
§ The Product Owner and the Developers collaborate in the refinement process as an ongoing activity.
* as well as decomposing and removal of items
Courtesy: https://www.agilegenesis.com/post/q-of-the-week-what-is-the-responsibility-of-the-development-team-in-product-backlog-refinement
17:52
01:47

38. Tips for maintaining a
healthy product backlog

39. 39
Which Product Backlog appears healthiest?
What’s wrong with the other backlogs?

40. 41
Backlog Depth & Order
Typical goal to maintain 1 to 3 sprints of ready pointed
stories
Arguably less is more, since a backlog is inventory and
inventory is waste
Order backlog based on risk, value, urgency, dependency,
and tentative sprint goals
Items lower in the backlog generally larger and not ready
(e.g., epics, not stories)
Number of backlog items should be relatively fewer in
number
Groom backlog to remove lower value items (consider
rejecting or deferring)
Assume team completes
~10 stories per sprint with
average velocity 40 points
Top backlog: ~20 ready
stories mostly 2 to 5 points
Mid backlog: ~15 stories
not ready stories not
pointed roughly 5 to 21
points
Bottom backlog: ~10 epics
perhaps sized S, M, L or
20, 40, 100 points
Tips for a healthy product backlog
Image: Essential Scrum: A Practical Guide to the Most Popular Agile Process

41. 42
8 pts
Ready
If points not converging during poker planning, then
not ready
Do not repoint incomplete story started in prior sprint
Tips for a healthy product backlog:
Pointing
Leverage spikes for research needed to get stories to
ready
Do repoint stories not started in planning if learned
something new
Independent
Negotiable
Valuable
Estimable
Small
Testable
8 pts
Not done 5 pts
Done
3 pts
To do
5 pts
Ready
3 pts
Ready
This sprint Next sprint
18:06
01:47

42. 43
What size stories might be ideal for your sprint backlog?
Assume team’s average velocity is 40 points for 2-week sprint
8
5-point stories
8 point story
8 point story
8 point story
8 point story
5
8-point stories
21 point story
2
21-point stories
13
3-point stories
13 point story
13 point story
3
13-point stories
2-point
stories
20

43. 44
Product backlog items with less detail are better
than product backlog items with more detail
Just enough may be more for a new team
Just enough will be less for a mature team
<=> ?
->+ !
Less is More Imperfect is Good
Product backlog items need not be perfect; if they
are, then you are spending too much time
Product backlog items are conversation starters;
anticipate refining items during refinement
Purphiktlee inpurphikt?
Perfectly unperfect!
Tips for a healthy product backlog item
Just enough and just OK is just right

44. Potential backlog
refinement anti-patterns

45. 47
Independent?
- Team member may write own
tasks, requiring another story
written by another member to
be developed in parallel
Negotiable?
- Product owner may be removed
from the discussion and shared
understanding, questioning story
in sprint review
Valuable?
- Story may be written from
developer’s perspective without
understanding the desired
outcome for the user
Potential Anti-pattern:
Developers write stories, not product owner
While the product owner may delegate these activities to the team or team members, why isn’t the product owner more involved?
Estimable?
- Team members might defer to
the individual who wrote the
story with risks and
opportunities overlooked
Small?
- Stories may be split horizontally
by layer or skill set, rather than
vertically, reducing collaboration
and cross skill development
Testable?
- Acceptance criteria may become
a task list, as the developer
considers how the work will be
delivered, not user expectations
18:17
01:47

46. 48
A story to write a story,
perhaps with signoff?
Maybe even design teams
adding to cycle time?
Acceptance criteria and
definition of done?
Requirements Story Design Story Acceptance Story
Best architecture and designs
emerge
Business and developers work
together daily
Software over documentation
Potential Anti-patterns:
Stories before ready and after done
Consider a Scrumban workflow like Professional Scrum Kanban to track story before ready and after done.
Continuous integration
and continuous delivery?
Deployment Story
Give them the environment
they need
What was transformed: traditional
practices or Agile processes & tools?

47. 49
Activity Defects Kaizens
Want velocity to decrease if
create defects!
Always pull an improvement
and just do it?
Want velocity to increase as
routine activity automated!
Potential Anti-patterns:
To point or not to point?
What would be the impact on velocity if pointed or not pointed?
Spikes
Timebox instead of pointing,
but what size timebox?

48. 50
Resist the temptation to delve into the “how”
Discuss only enough to point confidently
If really need to consider “how” at length before
pointing, then consider adding a spike for
research
Discussing How Tasking
Resist the temptation to break down the story
into tasks during refinement
Acceptance criteria shouldn’t be a task list either
Potential Anti-patterns:
Implementation details
Leave these details for second half of sprint planning, when committing to do the work
1) Conduct analysis with business signoff
2) Design solution with architect approval
3) Write code with tech lead review
4) Test solution with QA manager check
5) Document support with manager signoff
6) Deploy with change control approval

49. 51
Backlog should be force-ranked ordered list
During refinement, may reorder, however, do not
recommend assigning a sprint
Promotes push instead pull culture*
*In sprint planning, if story does not align with
goal or velocity exceeded, team needs to push
story back to product backlog
Assigning Sprint Assigning Owner
Story owner or lead should never be assigned
Team member may volunteer to own or lead
story, but save that for sprint planning
Assign should be banned language in Agile*
*It’s unfortunate that our “Agile” tools use legacy
language like “Assigned” associated with
traditional push culture
Potential Anti-patterns:
Assigning promotes traditional push culture
ASSIGN
18:32
01:47

50. 52
NOT READY
Applying close enough rule during
the first round
Applying a not-so-close close
enough rule
Take the mode or the median
Don’t take the mean
Round up to next Fibonacci
If not close enough, do not point,
story not ready
Don’t be tempted to drop the
outliers
Not Close Enough Averaging No Consensus
Finding the mean requires extra effort,
potentially implies false precision, and
discourages finding consensus through
shared understanding
No consensus implies story not
estimable and therefore does not pass
INVEST criteria
Looses the conversation which can
generate a shared understanding and
identify the risks and opportunities
Potential Anti-patterns:
Not so close averaging
Scrum Inc promotes all these practices based on belief that estimation is wasteful and effort estimating should be minimized
5 5 8 8 8 2 3 5 8
1
3
3 3 5 8 8
5 5 8 8 8
6.8
5 5 8 8 8 2 5 5 5
1
3
5

51. 53
Continued Planning or Re-planning
Backlog refinement is pre-planning for future sprints, not continued
planning or re-planning for current sprint
Why is this happening?
• Was sprint goal well-defined?
• Were product backlog items ready?
• Did sprint planning skip tasking?
Potential Anti-patterns:
Backlog refinement as current sprint re-planning
Why?
What?
How?

52. 54
Potential Anti-patterns:
Shu-Ha-Ri
I suspect we all follow one or more of these anti-patterns; if they work for your team, great
Shu: When starting, I encourage following the rules, to create a solid foundation
Ha: Then experimenting, bending the rules, testing to see if you get better results
Ri: Eventually, we’ll just be Agile, transcending the rules, intuitively doing what works
Starting with Shu can eventually lead to Ri
Starting with Ha rarely leads to Ri without moving back to Shu
Image: https://www.lion.nu/agile-flow-shu-ha-ri/
transcendence

53. 55
Concluding Questions
Who follows one or more potential anti-patterns?
What are the negative impacts, if any?
Why have those anti-patterns developed?
What could you do to improve?
Did you come away with any take-aways?
What might you try in your next backlog refinement?
What was most valuable to you here?
18:41
01:47

54. Appendix 202

55. 57
Scrum Master’s Role Related to Refinement
No mention of the Scrum Master.
Other than ensuring that refinement happens, is productive and positive, and perhaps facilitating as
needed, what is the Scrum Master’s role in refinement?
Regarding the Scrum Master’s service to the Product Owner, the Scrum Master’s role is:
• Helping find techniques for effective 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;
On the other hand, the Scrum Master does not necessarily have to participate in refinement at all.
https://www.scrum.org/forum/scrum-forum/28709/product-backlog-refinement-scrum-masters-role
18:45
01:47

56. 58
Who
Story Workshops
Where: in-person at a whiteboard with markers and stickies, if possible
Quarterly objective
Story mapping
User story writing
What
Whole team
Stakeholders and users, optional
6 to 12 participants
Start of project to build initial backlog
Then quarterly or every major release cycle
A couple hours to a full day
Focus on a single major objective
Minimum viable product increments
Better outcomes, better experience
When Why

57. 59
Users have Personas with Goal
Activity becomes Epics or Themes
Backbone becomes Features or Epics
User Tasks become Stories
First Release Slice is MVP
User Goal Story Mapping
https://www.beliminal.com/quickstart-guide-to-user-story-maps/

58. 60
Patton’s Story Mapping Overview
http://www.jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf

59. 61
A Smart Summary
for just enough
https://ghinda.com/blog/learning-notes/2020/how-to-reduce-time-spent-in-backlog-refinements.html
https://www.scrum.org/resources/blog/art-product-backlog-refinement
Sprint
Sprint

60. 62
David Hanson
dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/
https://www.slideshare.net/DavidHanson5

62. 64
What Else?
Estimating epics: https://www.slideshare.net/DavidHanson5/epic-estimation-2019