Backlog Maintenance Iteration Planning Daily Standup Retrospective ShowcaseDoing the work Blockers
Clarify - HIGH
Clarify - LOW
Ideate - High
Ideate - LOW
Clarify ImplementIdeate Develop Clarify ImplementIdeate Develop
ImplementIdeate Develop
Clarify ImplementIdeate Develop Clarify ImplementIdeate Develop
Clarify ImplementIdeate Develop
Consider building afeeder mechanismfor ideas (empathymap, stakeholder
group)
Clarify ImplementIdeate Develop
Develop - HIGH
Develop - LOW
Implement - HIGH
Implement - LOW
Apply acommon set
of "done"critieria forevery story
Clarify
Try a 5 Why'sexercise
Do a root causeanalysis
Team will enjoythis; consider
rotating who is"scribe" so each
team member getsto have fun
Team could spendtoo much time on
each idea; considersetting a time limit
for discussion
Avoid lettingit become asolutioning
session
Team will enjoythis; consider
rotating who is"scribe" so each
team member getsto have fun
Team could spendtoo much time on
each idea; considersetting a time limit
for discussion
Be sure to clarifyONLY the tasks;
don't try to rewritethe acceptance
criteria
Avoid thetendency to
over-engineerthe solution
Go for novelapproaches inwhat stories
you write andwhy
Highlight theessence ofthe story
Refine yourdone
conditions
Refineacceptance
critieria
Avoid thetendency toover-analyz
e
Avoid "paralysis"because you feellike some detailis not perfectly
clear
This is agile, "goodenough" is OK (you
can fix it later). Makean assumption anddocument it so you
can move on
Make sureyou haveSMARTtasks
Even if not a"development" team,
consider usingZenHub as an easyway to keep track ofany assumptions you
have to make
Make sure yourdone conditionsare applicable toall stories (have
internalconsistency)
Be open tonovel
approachesto solving a
blocker
Document yourassumptions
and revisit at theretrospective
Avoid writingstories that do
not meet auser need
Don'trewrite
acceptancecritieria
Make sureto writeSMARTtasks
Don't let a blockerlinger; any oneperson blocked
means the wholeteam's velocity is
at stake
Look for "goodenough"
solution, notthe "best"solution
Make sureyour stories
are groundedin user needs
Avoid thetendency toget bogged
down inpro/con lists
Try anevaluation
matrix to weighthe criticalfactors of a
story
For Priority, tryrunning stories
through atournament (A>B,A>C, C>B, D>A) =
D,A,C,B
Get a basicplan of actiontogether andkeep moving
Avoidover-analyzin
g; keepmoving
Don't baseyour ideas onan assumed
problem
Make sure to get toa comfort level so
the one who isblocked feels theright problem is
being addressed
Determine howyou will completethe stories; what
are the necessarytasks?
Avoid "paralysis"because you feellike some detailis not perfectly
clear
Get to a placewhere you can
move forward onan MVP-type
problemstatement
Avoidblameshifting onthings that did
not go well
Be sure totimebox what did
not go well
If there are a lot ofthings to debrief,consider doing anideation session
separately
Make sure tocapture stories
from yourprevious
retrospective
Make sure tocapture stories
from yourprevious
retrospective
Avoid tendencyto delve into too
much detailduring
showcase
Encouragecuriosity
Encouragecuriosity
Encouragecuriosity
Focus onvalue, notpolished
presentations
Avoidtendency toshowcase
complicatedscenarios
Focus ontelling a
story
Try to think of thesimplest scenario that
you can showcase(hint: focus onstory/feature
acceptance criteria)
Focus on thevalue of theoutcome, as
opposed to theprocess or
details
Ask yourself,"why does
this productmatter?"
Avoid trap ofskimming over
AcceptanceCriteria
If you have ahigh clarifier onyour team, let
them be "scribe"for story writing
Make sureto writeSMARTtasks
Team will wantto "gloss over"
tasks assomething "we
all know"
Keep trackof yourbacklog
items
Find easy ways tocapture your workprogress (eg, useGitHub issues and
comments)
Team members willhave a tendency to
make implementationdecisions and forgetto share with the rest
of the team
Document yourprogress (evenif not related to
a story)
Read up ondifferent
Retrospectivetechniques
(retrium.com)
Use powerfulquestions as a
way toencourage
input
askpowerful
(clarifying)questions
Team membersmay be
reluctant todiscuss issues
askpowerful(ideating)questions
askpowerful
(developing)questions
Avoid trap ofnot listeningcarefully tostakeholder
questios
Consider thetechnique of "repeatback the question"(so stakeholder can
confirm/clarify) beforeanswering
Team will havetendency to write
Acceptancecriteria that are"how' and not
"what"
Don't beafraid ofLOTS ofstories
Put yourself inthe shoes of a
particulartype of user
Avoid the trapof not clarifyingthe "who" in the
user story (ie,the "as a ...")
Express ideasby telling a story
about how aspecific usercan benefit
Focus yourdiscussions onthe "what" of
each story, notthe "how"
Team will want to"slip into
solutioning"which is not part
of backlogmaintenance
Avoidtemptation tochange theAcceptance
criteria
Focus on whatthings need to bedone to meet the
acceptancecriteria
Focus on"how" ideas,not "what"
ideas
Use yourclarifiers anddevelopers topare down list
of tasks
as "howmight we ... "questions togather task
'ideas'
Avoid addingnew stories
while refiningprioritized
stories
Avoid doingmore workthan is trulynecessary
Focus onthe explicit
task(s)
Add newideas to theparking lot
Avoid trying toover thinkmultiplepossiblesolutions
see theblocker as an
MVP in amicrocosm
Save"solution"
discussionsto end of
retrospective
During discussionof what didn't go
well, team willwant to spend
time solutioning
highlightthe
essence
highlightthe
essence
Avoid trap ofspending too
much timesolutioning;
showcase is forLISTENING tostakeholders
Avoidoversellingthe value /outcome
Reassurestakeholder(s)that multiple
solutions existbut don't go into
detail
Remember to"W.A.I.T."(why am Italking)
Team will want toadopt the first ideathat comes along,
instead ofexploring options
Considerregularly
scheduledDesign Thinking
exercises
try anempathymappingexercise
Avoidsolutioning or
jumping on thefirst solutionmentioned
Ask this final questionbefore you finishfleshing out each
story: "is there anyway to make this
simpler or easier?"
Try not tojump on the
first story youlike
No iteration plan isperfect; avoid the trapof continuing to workon a task that is notpanning out simply
because it's part of thestory
The next DailyStandup is an
opportunity to raisethe issue and tweak
your plan ifsomething is not
going well
Engage newideas on their
merits, nottheir pitfalls
Don't kill an ideaon how to solve
a blocker justbecause itdoesn't "fit"
Affirm yourteammate by
affirming aproposed
idea
Try the POINtmethod
(Positives,Opportunities,Issues, New
Thinking)
The team will notwant to spend
enough time onpossible solutionsto issues raised in
the retro
highlight theessence of
whatworked/didn't
work
Avoidfleshing outnew ideas
Pick 1 thing to fixso as not to
overwhelm theteam with having
to produce a lot ofideas
Don't reverseengineer
what didn'tgo well
Avoid falling intodefensiveness
whenstakeholders
give feedback
Don't prematurelycut off a
productivebrainstorming
session with thestakeholder
Allow timefor Q&A
Stay in the mindsetthat by showing themwhat they asked for,
you are reallytriggering them tofurther clarify what
they really want
Avoid trap of"killing" ideasbecause ofpotential
risks/costs
Limit potentialrisks/costs to only
those that areessential
acceptancecriteria
Keep storysizing in mind
whendetermining thenumber of tasks
It's OK toclarify what
the story willNOT
accomplish
Avoid the tendency to"pile on" whenblockers are
mentioned (i.e., addingblockers not essentialto acceptance criteria)
"Just thefacts,
ma'am"
Be disciplinedabout using
"parking lots"(post-standup
follow upmeetings)
Avoidover-solutio
ning
Don't let yourdesire to "dig in"
to each issuederail the stand
up
Stick to thestories in
progress orblockers
Don't moveforward without
hearing fromevery team
member
Remember thestandup is to share
updates on stories inprogress; move the
status forward and getto blockers (or back to
work!)
Don't engageblockers during
standup
Consider asking theteam to write whatthey are going to
share at the standupin Slack before the
standup
Savesolutions toblockers for
post-standup
Consider asking theteam to write whatthey are going to
share at the standupin Slack before the
standup
Team will have atendency to want toexplore solutions to
blockers in detail(and derail the
stand-up)
Save ideasfor
post-standup/ backlog
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
Avoid tendency toidentify blockers
which are notstrictly related to
acceptancecriteria
Keep theiteration
flow going!
Put areas ofimprovementinto parkinglot (for retro)
Avoid doingmore workthan is trulynecessary
Avoidadding new
tasks
Focus onthe explicit
task(s)
Add newideas to theparking lot
Blockers arelogjams that needto be removed /
resolved; notnecessarily solved
Select theeasiest
solution tounblock the
blocker
Resolve,don't
"solve"
Pick upthoughts
from parkinglot
Time box the"what didn't
go well"discussion
Add solutionthoughts toparking lot
For complexproblems,
consider anexploratory taskfor the backlog
Pick 1 thing tofix so as not
to overwhelmthe team
Avoidfrightening
stakeholderswith "riskoverload"
Prepare inadvance whichkey risks youwant to havestakeholders
clarify
Supportshowcase
with detailsonly when
needed
Be sure tocheck off tasks
and movestories as theyare completed
Save newtasks for theparking lot
Don't addtasks to your
"to-do" list thatare not in the
story
Pair with a highimplementer
when workingon a story
Establishteam rewards
for closingstories
Don't redefinethe story afteryou commit to
it
Consider whattechnical debtneeds to be
reduced
Create a "punchlist" of tasks forthe story you
select
Ensure the teamfocuses on
story-relatedtopics
Try not to pushor oversell your
idea forresolving a
blocker
Allow time forreflection
Celebrate teamaccomplishments
Don't blow offteam
achievements
Ask: "how might wemake this better?" (ie,
is this really doingthe best job of
meeting acceptancecriteria)
Don'tassume it's
"goodenough"
Ask: "is this thebest way toremove thisblocker right
now?"
Be deliberate inconsidering
quality
Outcomemust be to
resumeforward
progress
Don't focuson
solutioning
Focus ontask/storyprogress
Be sure totimebox thestandup and
move non-storyitems to
post-standup
Focus onbreaking the
iterationlogjam
Don't rushtopics that needto be covered -but do so in the
post-standup
Be open tonovelty inhow youexecute
tasks
Don'tunderestimate
the effort
Team willhave a
tendency togloss over
details
Considerthe effortbounds ofthis story
Ask key openquestions from theuser's perspective(what would make
the experiencebad)
Assumemore effort is
necessarythan less
If in doubton sizing,go with
larger size
Ask: "whatare we
missing?"
Team will have atendency to latch on
to first way toimplement instead
of consideringalternatives
Allow time foreach story to
consideralternative
solutions beforewriting tasks
Avoid"perfecting"your work
Don't be"done" with astory/task too
quickly
Take time in theiteration to
improvefunctionality
Focus on "how"the tasks shouldanswer the story
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank Team will want topick 1st way to
remove blocker(which may notbe best way)
Take the timepost stand upto talk through
blockers
Team membersmay not get toroot cause of
problems
Don't assume theteam will
automatically getbetter based on
informationgathered
Each retro shouldend with team
commit to makesomething better
Don't assume theteam knows how
to get better
Make sure retrohas time box forconsidering how
to get better
Capturestakeholderfeedback on
areas forimprovement
askpowerful
(developing)questions
Probe newrequests from
stakeholders toask whichalternative
solution theywould like
Trap isassuming
stakeholdersknow whatthey want
Reinforce thatstory should
focus onoutcomes that
appeal tostakeholder
Team may want to"skip" writing
complete storyand completeacceptance
criteria
Take time towrite complete
story (as a, Iwant, so that)
Don't rush thetime it takes toreach shared
understanding
Don'tcommit to a
story toosoon
Stay in touchwith your teamabout what you
are doing (orhave done)
Don't let yourdesire to get
things done get inthe way of gettingthings done right.
Make sure team fullyunderstands what itis committing itself
to before putting thestory into the
iteration
Avoid the trapof taking on
too manystory points
Team will havea tendency to
avoiddocumenting
progress
Leverage toolsthat make
documentingprogress easy(e.g. GitHub)
Team memberswill have a
tendency toreport too much
detail
Ask the team towrite what they
are going to shareat the standup inSlack before the
standup
Make sure yoursolution for the
blocker covers allaspects of the
blocker
Ask: "is this thebest way toremove thisblocker right
now?"
Allow forfeedback to
improvealternatives
Don't movetoo quickly to"what's next"
Use team'ssuccess to buildan even better
backlog
Givestakeholders
time to reviewand ask
questions
Avoid temptation tomove quickly
through showcasewithout allowing
time for Q&A
Open yourplanning call byrestating next
milestone team istrying to achieve
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
Don't assumeyou know yourstakeholder's
requirements /expectations
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank Team will have atendency to notwant to focus onclosing out tasks
in a timely manner
Consider using atask burn downchart to clearlysee remaining
work
Team will tendto be vague inreporting workaccomplished
Considernumbering tasksfor iteration and
have teammembers report by
task number
Consider asking theteam to write whatthey are going to
share at the standupin Slack before the
standup
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
Team collaboration do's & don'ts
Don't writestory tasks
yet
Do this
Avoid this
Legend
Te
am P
refe
ren
ce
Agile Practice
Clarify preferenceEnjoys exploring challenges and opportunities�Likes to examine the detailsWants a clear understanding of the issue�Prefers a methodical approach to solving problems�May suffer from “analysis paralysis”
Ideate preferenceLikes to look at the big picture�Enjoys toying with ideas and possibilitiesLikes to stretch his or her imaginationEnjoys thinking in more global and abstract termsTakes an intuitive approach to innovationMay overlook details
Develop preferenceEnjoys putting together workable solutions�Likes to examine the pluses and minuses of an ideaLikes to compare competing solutionsEnjoys analyzing potential solutions�Enjoys planning the steps to implement an ideaMay get stuck in developing the perfect solution
Implement preferenceLikes to see things happen�Enjoys giving structure to ideas so they become a realityEnjoys seeing ideas come to fruitionLikes to focus on “workable” ideas and solutionsTakes the Nike approach to innovation (i.e., “Just Do It!”)May leap to action too quickly
