Product Owner Flashcards
A legacy list of requirements is…
a liability, not an asset
Strategies to prioritize the backlog
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?
the 20/30/50 rule
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
last responsible moment
the act of delaying the decision until the cost of not making one becomes greater than the cost of making it
DEEP for product backlogs
Detailed Appropriately
Estimated
Emergent
Prioritized
Elements of the Product Backlog Item
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
Each item should require 3-5 pieces of ____
acceptance criteria
If some items have more than 5 acceptance criteria
break down the item
Sprint planning consists of 2 parts:
- 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
- Dev team creates a plan to tackle each item for the sprint
Sprint planning is timeboxed to
8 hours for 1 month sprints and proportionately lower for shorter sprints (4 hours for 2 weeks)
Estimate in
complexity points, not time
Fibonacci sequence 0 to 21, 1 point = half-day’s effort
Planning poker
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
Estimates should encompass
everything, testing and dev
Estimates are a forecast, not a
commitment
Daily Scrum key aspects
timeboxed to 15 mins
enables planning at the daily level
keeps everyone aligned and on track
Daily Scrum is not a
status update meeting but a planning meeting
3 questions to answer at the daily scrum
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
Removing the impediments from the path is the responsibility of
the scrum master, however, the PO can help out
Participants of the daily scrum meeting
the dev team, not PO & SM (they can be there but they don’t have to speak)
Scrum team should commit ___% of their time to refinement
10%
Backlog refinement requires
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
Blocking and Tackling…
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
Goals of Blocking
- Explain the objective of next sprint
- Explain how each item selected contributes to that
- Identify any issues that would block any item from selection for the next sprint
- Take action items for any issues that are unable to be resolved during the session
Goals of Tackling
- Consider each selected item in more detail
- Review Acceptance criteria for each item
- Discuss supporting materials such as wireframes
- Follow up on outstanding action items
Spikes are raised
during Blocking, as a way to investigate certain unknowns before committing to anything
Spikes should have …
a clearly defined goal (what should be learned) and in what time
schedule spikes
1 sprint ahead
POs next steps at refinement
further refine each item selected for the next sprint
answer any outstanding questions
Yesterday’s weather
the idea that the team’s velocity is best predicted by their last sprint’s results
Elements of a sprint review
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
Prepare for sprint reviews
Make a list of completed items
make an agenda, minimizing switching between people
send the invitations to the most relevant folks
timeline for the sprint velocity being stable
4 sprints
how to handle feedback during the sprint review
take down in a feedback grid, but don’t commit during review until everything is considered
traits for retrospective
timeboxed at 3 hours for 1 month sprint, but proportionately smaller (1.5 for 2 weeks)
goals for retro
inspect the sprint for processes
identify things went well/didn’t go well
create a plan for improvement in the next sprint
who usually facilitates the retro?
scrum master
What’s a release plan
a projection over time for a few next release cycles of what themes, goals and metrics we’re planning on for the future
A way to test how good the user stories are
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