Agile  Coach  and  Scrum  Master  Resume  Writing  

By  Damon  Poole,  Chief  Agilist  at  Eliassen  

Why  The  Right  Resume  is  so  Important  

Here  is  a  story  about  why  it  is  so  important  to  have  the  right  resume.  It  is  also  the  
story  that  inspired  the  creation  of  this  document.  A  while  back,  I  was  interviewing  a  
candidate  for  an  Agile  Coach  position.  The  resume  was  impressive,  but  the  
information  related  to  Agile  Coaching  was  not  easy  to  find  in  a  quick  skim  of  the  
resume,  and  as  a  result  of  an  interview  I  found  that  not  all  of  the  candidate’s  
relevant  experience  was  listed.  The  process  of  placing  a  candidate  has  many  steps  
and  in  this  case,  the  client  saw  the  original  resume  before  I  was  able  to  give  the  
client  my  impression  of  the  candidate  and  they  rejected  the  candidate  based  on  their  
resume  alone.  
 
I  decided  to  contact  the  client,  describe  the  candidate’s  relevant  experience  and  
convince  them  to  do  a  phone  screen  with  the  candidate.  They  did  the  phone  screen  
and  later  made  the  candidate  an  offer!  
 
You  probably  already  have  an  amazing  resume.  But  if  you  are  applying  for  a  specific  
position,  it  is  good  to  make  it  easy  for  the  person  interviewing  you  to  find  the  
specific  information  that  shows  that  you  are  a  good  fit  for  the  position.  The  best  way  
to  do  this  is  to  is  focus  on  the  specific  items  that  highlight  your  relevant  experience.  
One  way  to  focus  is  to  create  a  resume  that  is  tailored  to  one  specific  position  and  
leaves  out  any  experience  that  is  not  directly  relevant.  Another  way  is  to  organize  
your  experience  into  categories  so  that  interviewers  can  easily  find  exactly  what  
they  are  looking  for.  
 
The  next  question  is,  what  is  “relevant  experience”  when  it  comes  to  being  an  Agile  
coach  or  Scrum  Master?  There  are  several  categories  of  relevant  experience:  your  
Agile  knowledge,  your  Agile  experiences,  the  scope  and  value  of  your  experience,  
and  your  participation  in  the  Agile  community.  

Agile  Knowledge  
First,  it  is  good  to  demonstrate  your  level  of  Agile  knowledge.  You  don’t  have  to  
prove  it  in  your  resume,  that  is  what  the  interview  is  for,  but  you  do  need  to  list  it  in  
order  to  increase  your  chances  of  making  it  to  the  interview  process.  This  is  also  a  
good  way  to  demonstrate  that  you  understand  that  “Agile”  encompasses  a  wide  
range  of  methods,  practices,  and  technologies.  Don’t  list  things  that  you  have  heard  
about  just  to  make  a  good  impression.  If  you  can’t  back  it  up  in  the  interview,  you’ll  
make  a  bad  impression.  
 
You’ll  also  want  to  be  clear  on  how  much  experience  you  have  in  a  particular  area  of  
Agile.  For  instance,  “Have  stood  up  20  teams  using  Scrum  and  used  Kanban  with  one  
team.”  At  the  end  of  this  document  there  is  a  list  of  Agile  areas  of  knowledge  that  

 
  

you  can  for  reference  to  remind  you  of  experience  that  you  may  have  forgotten  to  
list  on  your  resume.  Again,  be  sure  that  you  can  back  it  up  in  an  interview!  

Agile  Experience  
The  main  goal  of  an  Agile  coach  or  Scrum  Master  is  to  educate  people  on  how  to  
work  in  an  Agile  way  and  how  to  “be  Agile.”  This  applies  to  individuals,  teams,  and  
organizations.  So,  you  need  to  list  experience  that  clearly  illustrates  how  you  helped  
individuals,  teams,  and  organizations  how  to  work  in  an  Agile  way  and  to  “be  Agile.”  
 
The  best  examples  are  ones  that  clearly  show  your  direct  involvement  with  an  Agile  
team.  For  instance,  running  a  workshop  for  a  team  or  for  a  group  of  product  owners  
on  how  to  write  a  good  user  story  is  much  more  relevant  than  circulating  a  
document  that  describes  the  new  format  for  user  stories  and  how  to  enter  them  into  
the  Agile  Project  Management  tool.  
 
A  good  way  to  think  of  examples  of  your  experience  is  to  look  at  your  areas  of  Agile  
knowledge  and  think  of  how  you  imparted  that  knowledge  to  others.  Did  you  have  
one-­‐on-­‐one  sessions  with  individuals?  Did  you  run  the  standups  for  a  new  team  to  
demonstrate  a  well-­‐run  standup  meeting  to  a  Scrum  master  that  you  were  coaching?  
Did  you  run  a  workshop  on  a  particular  topic?  Did  you  bring  new  retrospective  
techniques  to  a  team  based  on  a  blog  you  read  or  a  conference  you  attended?  Did  
you  pair  with  a  developer  to  show  them  some  refactoring  techniques  that  could  help  
them  in  their  particular  situation?  

The  Scope  of  Your  Agile  Experience  

The  best  Agile  Coaches  and  Scrum  Masters  can  draw  on  a  wide  range  of  experiences  
from  a  wide  range  of  different  circumstances.  It  also  means  being  able  to  adapt  to  a  
new  situation  by  synthesizing  new  ideas  from  past  experiences.  That’s  hard  to  show  
in  a  resume,  but  a  good  indicator  is  the  breadth  and  depth  of  experience  that  you  
show  on  your  resume.  When  describing  your  experience,  mention  the  scope  of  your  
experience  whenever  you  can.  
 
Rather  than  say  you  “stood  up  new  teams,”  be  specific  about  how  many  teams,  in  
how  many  different  areas  of  the  company,  and  how  big  the  teams  were.  It  is  much  
more  illustrative  to  say  something  like  “Stood  up  5  new  teams  for  enterprise  
solutions,  payroll,  and  digital  products  in  6  months.  All  teams  were  7-­‐10  people  in  
size.  Also  coached  the  managers  involved  with  these  teams  on  their  new  
responsibilities.”  

The  Value  You  Provided  

Clients  are  very  wary  of  activity  that  produces  no  apparent  results.  Of  course,  the  
best  coaches  and  Scrum  Masters  don’t  solve  client  problem  themselves,  but  rather  
find  ways  to  help  clients  solve  problems  on  their  own.  But  you  still  need  to  find  
examples  of  how  you  coached  people  to  solve  their  own  problems  and  that  then  
resulted  in  something  that  people  consider  valuable.  
 

 
  

Don't  assume  that  the  person  reading  your  resume  understands  Agile  the  same  way  
you  do  and  will  make  the  connection  between  the  practices  you  helped  to  
implement  and  the  results.  The  more  the  reader  sees  the  connection  in  your  resume  
between  what  you  did  using  Agile  and  results  that  they  are  interested  in,  the  more  
likely  they  are  to  be  interested  in  engaging  your  services.  
 
It  won’t  be  possible  to  show  a  direct  correlation  between  your  work  and  a  valuable  
end  result  in  all  cases,  but  the  more  examples  you  have,  the  better.    Here  are  some  
examples:  
• Suggested  one  new  question  to  ask  after  the  standup  which  doubled  the  
number  of  done  stories  per  iteration  across  all  teams.  
• Explained  Kanban  to  a  team  that  was  struggling  with  Scrum  and  they  asked  
me  to  help  them  move  to  Kanban  which  cut  their  cycle  time  in  half.  As  a  
result,  many  customers  specifically  mentioned  dramatically  increased  
responsiveness  as  a  reason  for  higher  satisfaction  scores.  
 
With  regards  to  the  “one  more  question”  example  above,  you  don’t  need  to  go  into  
detail  on  each  item.  It  is  okay  to  have  some  items  which  require  further  explanation.  
If  the  interviewer  is  interested  in  that  area  of  your  experience,  it  will  serve  as  a  good  
conversation  starter,  especially  if  you  can  show  the  value  that  was  provided.  

Participation  in  the  Agile  Community  

Many  coaches  get  their  start  as  Scrum  Masters  or  Product  owners  and  their  first  
introduction  to  Agile  was  either  from  another  practitioner  in  those  roles  or  from  
getting  Scrum  Master  and/or  Product  Owner  training.  The  remainder  of  their  
experience  is  then  self-­‐taught  based  on  trying  things  to  see  what  works  and  
referring  to  a  book  or  two.  
 
This  is  certainly  a  good  place  to  start,  but  the  most  successful  Agile  coaches  and  
Scrum  Masters  spend  a  lot  of  time  interacting  with  the  Agile  Community  to  get  new  
ideas  and  techniques.  This  comes  in  many  forms,  including  writing  a  blog  and  
participating  in  discussion  with  others  in  the  Agile  community  on  that  blog,  
participating  in  various  online  Agile  forums  and  communities,  attending  Agile  
conferences,  reading  many  Agile  books,  presenting  at  conferences,  participating  in  
local  Agile  community  groups,  and  creating  or  participating  in  Agile  Coaching  
Circles.  Make  sure  to  list  items  that  show  your  participation  in  the  Agile  community.  
It  doesn’t  prove  your  ability  to  coach,  but  it  is  a  hallmark  of  the  best  Agile  coaches.  

Additional  Tidbits  
Keep  in  mind  that  how  you  frame  your  experience  matters.  While  you  may  have  
worked  at  a  small  company  and  thus  had  “members  of  the  whole  company  involved  
in  the  product  vision  workshop,”  that  may  not  play  well  if  you  are  interviewing  at  a  
large  company.  Instead,  consider  rewriting  that  experience  to  focus  on  what  is  
generally  applicable  like  this:  “made  sure  that  all  relevant  stakeholders  for  product  
X  were  involved  in  the  product  vision  workshop.”  
 

 
  

It  is  ok  to  reframe  experiences  so  that  people  in  different  circumstances  can  relate  
to  them,  but  always  make  sure  to  only  write  what  you  can  back  up  in  interviews  and  
reference  checks.  In  this  example,  in  the  interview  you  could  then  elaborate  that  it  
was  a  small  company  and  you  in  fact  had  people  from  the  whole  company  involved.  

Areas  of  Agile  Knowledge  

This  is  a  list  you  can  use  to  remind  yourself  of  things  you  may  want  to  list  on  your  
resume.  Be  careful  to  only  include  things  that  you  feel  you  know  well  enough  to  
teach  other  people,  not  just  things  you  have  heard  of  or  are  familiar  with.  This  is  by  
no  means  an  all-­‐inclusive  list,  it  is  only  intended  to  give  you  an  idea  of  what  kinds  of  
knowledge  is  expected  of  an  Agile  Coach  or  Scrum  Master.  

• Scrum  
• XP  
• Kanban  
• TDD  
• BDD  
• ATDD  
• Acceptance  tests  
• Planning  Poker  
• Story  points  
• Agile  estimation  
• Empathy  maps  
• Shared  visioning  
• Jira  
• Version  One  
• Rally  
• Cruise  Control  
• UBuild  
• Gerkin  
• Cucumber  
• Retrospectives  
• Product  Owner  role  
• Scrum  Master  role  
• Agile  Coach  role  
• Agile  Tester  
• Refactoring  
• Story  splitting  

Agile  Experience  Examples  

These  are  examples,  make  sure  to  make  your  resume  unique  by  describing  your  
experiences  uniquely.  Don’t  just  copy  and  paste  from  these  lists,  make  sure  to  use  
these  lists  to  act  as  a  reference  to  remind  yourself  of  your  own  experiences  that  you  
have  forgotten  to  list  on  your  resume.  These  lists  are  also  intended  to  let  you  know  

 
  

what  kinds  of  experiences  that  clients  find  valuable  when  hiring  an  Agile  Coach.  
 
• Introduced  Agile(or  Scrum,  or  XP,  or  Lean,  or  Kanban)  to  organization  
• Stood  up  X  teams  using  Scrum  (or  XP,  or  Lean,  or  Kanban  or  just  plain  Agile)  
• Provided  CSM  training  
• Provided  a  story  writing  workshop  
• Provided  an  Agile  101  Class  
• Provided  Product  Owner  training  
• Facilitated  backlog  grooming  (or  standup  meetings,  or  iteration  planning,  or  
iteration  review,  or  retrospective)  
• Acted  as  Scrum  Master  (or  product  owner)  for  X  iterations  (or  sprints)  
• Taught  TDD/ATDD  to  20  developers  over  the  course  of  3  months  
• Convinced  management  to  buy  a  new  machine  to  support  Continuous  
Integration  
• Product  visioning  workshop  to  get  whole  team  on  the  same  page  
• Helped  teams  understand  the  importance  of  velocity  and  got  them  to  
measure  it  and  use  it  for  planning  
• Used  value  stream  mapping  to  communicate  bottlenecks  and  facilitate  
process  improvement  
• Worked  with  teams  to  help  them  understand  the  importance  of  sufficient  
documentation  for  harmonious  collaboration  between  departments  and  
teams  
• Start  accurate  project  metrics  to  be  maintained  by  the  teams  to  include  sprint  
burndown,  cost  per  story  point,  and  budget  burndown  
• Helped  teams  create  presentable  data  for  executive  decision-­‐making  
presentations  
• Coached  decision  makers,  developers,  architects,  infrastructure  engineers,  
product  owners,  business  analysts,  creative  and  QA  teams  on  how  their  roles  
change  in  an  Agile  environment  
• Encouraged  adjustments  and  adaption  by  all  teams  based  on  retrospectives  
morale  surveys  
• Guided  an  inexperienced  product  owner  through  three  different  release  
plans  in  the  span  of  four  months.  
• Coached  the  product  owner  in  the  art  and  science  of  writing  user  stories  that  
capture  requirements,  have  an  appropriate  scope  and  do  not  need  to  be  
decomposed  during  grooming.  
• Facilitated  preliminary  backlog  grooming  sessions  between  the  product  
owner,  the  lead  architect  and  the  engineering  manager.  
• Following  the  loss  of  the  team's  lead  architect,  coached  the  product  owner  
and  the  new  architect  through  preliminary  backlog  grooming.  
• Coached  the  product  owner  in  maximizing  return  on  investment  and  getting  
the  major  feature  epics  delivered  on  time  for  release.