Product Owner Flashcards

1
Q

A legacy list of requirements is…

A

a liability, not an asset

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Strategies to prioritize the backlog

A

business value - how much money we’ll make
business risk - what’s the risk and how we can mitigate
technical necessity - what do we need to do first technically to move ahead?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

the 20/30/50 rule

A

20% of the backlog should be well refined able to be picked up and worked on
30% suitable for a productive discussion with others
50% summary and possibly a description

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

last responsible moment

A

the act of delaying the decision until the cost of not making one becomes greater than the cost of making it

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

DEEP for product backlogs

A

Detailed Appropriately
Estimated
Emergent
Prioritized

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Elements of the Product Backlog Item

A

concise description of the intent of the item
estimate of the effort required
estimate of the business value the item will yield
order in the product backlog

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Each item should require 3-5 pieces of ____

A

acceptance criteria

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

If some items have more than 5 acceptance criteria

A

break down the item

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Sprint planning consists of 2 parts:

A
  1. PO introduces sprint objective and the items that will support it - Dev team debates and estimates and selects top items to go to sprint backlog
  2. Dev team creates a plan to tackle each item for the sprint
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Sprint planning is timeboxed to

A

8 hours for 1 month sprints and proportionately lower for shorter sprints (4 hours for 2 weeks)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Estimate in

A

complexity points, not time

Fibonacci sequence 0 to 21, 1 point = half-day’s effort

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Planning poker

A

everyone gets a deck of cards from 1 to 21
each votes for the item
if everyone places the same card, we’ll move on
if not, we discuss and do it again after the discussion
until the majority agrees

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Estimates should encompass

A

everything, testing and dev

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Estimates are a forecast, not a

A

commitment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Daily Scrum key aspects

A

timeboxed to 15 mins
enables planning at the daily level
keeps everyone aligned and on track

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Daily Scrum is not a

A

status update meeting but a planning meeting

17
Q

3 questions to answer at the daily scrum

A

what did i do yesterday to bring us closer to the spring goal
what will i do today to bring us closer
what is impeding my progress

18
Q

Removing the impediments from the path is the responsibility of

A

the scrum master, however, the PO can help out

19
Q

Participants of the daily scrum meeting

A

the dev team, not PO & SM (they can be there but they don’t have to speak)

20
Q

Scrum team should commit ___% of their time to refinement

A

10%

21
Q

Backlog refinement requires

A

1 hour of commitment per week
not all members are required to be in it
scrum masters are not required - usually a rep from every function

22
Q

Blocking and Tackling…

A

the first week of refinement is blocking: build an ordered list of items to be considered for the next sprint
tackling: refine each item so that it can be discussed in the next sprint

23
Q

Goals of Blocking

A
  1. Explain the objective of next sprint
  2. Explain how each item selected contributes to that
  3. Identify any issues that would block any item from selection for the next sprint
  4. Take action items for any issues that are unable to be resolved during the session
24
Q

Goals of Tackling

A
  1. Consider each selected item in more detail
  2. Review Acceptance criteria for each item
  3. Discuss supporting materials such as wireframes
  4. Follow up on outstanding action items
25
Q

Spikes are raised

A

during Blocking, as a way to investigate certain unknowns before committing to anything

26
Q

Spikes should have …

A

a clearly defined goal (what should be learned) and in what time

27
Q

schedule spikes

A

1 sprint ahead

28
Q

POs next steps at refinement

A

further refine each item selected for the next sprint

answer any outstanding questions

29
Q

Yesterday’s weather

A

the idea that the team’s velocity is best predicted by their last sprint’s results

30
Q

Elements of a sprint review

A

validates that the work is on track to meet stakeholder needs
engaging - everyone in attendance is fully interactive
informative and iterative - feedback feeds into the next sprints

31
Q

Prepare for sprint reviews

A

Make a list of completed items
make an agenda, minimizing switching between people
send the invitations to the most relevant folks

32
Q

timeline for the sprint velocity being stable

A

4 sprints

33
Q

how to handle feedback during the sprint review

A

take down in a feedback grid, but don’t commit during review until everything is considered

34
Q

traits for retrospective

A

timeboxed at 3 hours for 1 month sprint, but proportionately smaller (1.5 for 2 weeks)

35
Q

goals for retro

A

inspect the sprint for processes
identify things went well/didn’t go well
create a plan for improvement in the next sprint

36
Q

who usually facilitates the retro?

A

scrum master

37
Q

What’s a release plan

A

a projection over time for a few next release cycles of what themes, goals and metrics we’re planning on for the future

38
Q

A way to test how good the user stories are

A

INVEST

independent, does not depend on other user stories
negotiable, can be rewritten and reprioritized
valuable, provides some value to the user, keep technical stories to the minimum
estimatable, the team knows enough to estimate and slow enough
small, not too complex
testable, must be defined to the point that it can be tested