1.
Definition
of Ready
vs.
Refinement
What/When/Why?

2.
When you
think, PBI is
ready…

3.
Troy Magennis:
’When we asked someone to estimate how long it
will take to develop a feature or project they think
about how long it would take hands-on, with
PERFECT hand-off between teams and other staff
with the specialist skillset. This never happens.’

4.
What does it
mean that PBI
is ready?

5.
PBI is ready
when…
there is nothing to
add to
requirements.

6.
Ziv’s law:
’Requirements
never be
completely
understood.’

7.
Advise #1:
Don’t forget to ask
another question

8.
Advise #2:
If you have asked
all questions, ask
another

9.
Advise 3#:
Put the PBI into
app flow, to check
understanding

10.
Advise #4:
Ask more
questions about
PBI in the flow

11.
Advise #5:
Check on mockups,
if you didn’t forget
about anything

12.
Do you think,
you know
everything?

13.
Ziv’s law:
’Requirements
never be
completely
understood.’

14.
You have DoR –
the BASIS to start
PBI development

15.
What DoR really
is?
It’s a list of specific reqirements
details, established by dev team
with PO

16.
Dev team is ready
for next step –
Refinement

17.
Refinement is
a process of
taking care of
Product Backlog

18.
Helping
tool?
INVEST

19.
I – independant
N – negotiable
V – valuable
E – estimable
S – small
T – tastable

20.
Refinement flow

21.
Why do we create
PBIs according to
DoR and refine
them?
Because of a sense of the value.

22.
When there is a sense of the value, team is:
• self-organizing rather than role- or title-based
• empowered to make decisions
• ready to solve any problem
• committed to team success vs. success at any cost
• ready to own its decisions and commitments
• consensus-driven
- Lyssa Adkins

23.
https://www.linkedin.com/in/agatasobek/