THERE IS NO SPRINT ZERO.

Go!

Over  a  year  ago,  I  started  on  an  new  and  interesting  journey.    I  was  assigned  to  work  on  an  Agile  team.

I  came  from  a  traditional  waterfall  background.    I  had  a  clear  understanding  what  my  role  was  on  the  team.    What  my  deliverables  were,  how  long  it  would  take  to  create  them.

My  world  was  very  straightforward  then.

My  exposure  to  agile  prior  to  my  current  role  was  academic.    There  was  this  thing  called  sprints,  where  developers  did  short  bursts  of  work,  and  then  they  would  iterate.    And  UX  work  all  occurred  in  this  thing  called  Sprint  Zero.    Before  the  dev  teams  start  working.

This  presentation  is  my  experience  about  being  embedded  in  an  Agile  team  and  being  immersed  in  the  process.  As  you  can  imagine,  this  was  quite  the  change  for  me.      Interestingly  enough,  both  change  management  and  agile  talk  about  the  Five  Stages  of  Change  adoption.

This  is  based  on  the  Five  Stages  of  Grief.

I  will  use  this  model  to  share  my  experience.

D E N I A L

Denial  

For  me,  denial  often  presents  itself  as  optimism.    Hey,  Agile  is  new  for  me,  but  I  would  really  like  to  learn  about  it.        I’ll  still  be  able  to  do    my  usual  process  in  the  mystical  Sprint  Zero.

Not  the  case.

D E N I A L

Denial  

For  me,  denial  often  presents  itself  as  optimism.    Hey,  Agile  is  new  for  me,  but  I  would  really  like  to  learn  about  it.        I’ll  still  be  able  to  do    my  usual  process  in  the  mystical  Sprint  Zero.

Not  the  case.

O P T I M I S T I C

Denial  

For  me,  denial  often  presents  itself  as  optimism.    Hey,  Agile  is  new  for  me,  but  I  would  really  like  to  learn  about  it.        I’ll  still  be  able  to  do    my  usual  process  in  the  mystical  Sprint  Zero.

Not  the  case.

I  am  part  of  a  Product  Team.    The  product  team  is  made  up  a  lead  from  each  functional  group.    There  is  a  dev  lead,  a  UI  lead,  a  QA  lead,  myself  as  the  UX  lead  and  the  product  manager  along  with  the  Scrum  Manager.

We  created  the  Initial  backlog  together.    This  enormous  sprawl  of  sticky  notes  is  a  our  project?    This  is  the  documentation?    This  is  the  map  we’re  going  to  follow?    No  requirements,  no  speciRications?

JSTOR HOME SEARCH BROWSE MyJSTOR

<Coverage>, <Volumes>Published by: <Lorem Ipsum Press>

Books in Series

<Series Title>

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci malesuada diam, quis dignissim leo augue eu risus. Duis bibendum, dui sit amet suscipit pellentesque, felis tortor auctor augue, ut dapibus ipsum urna in velit. Sed ultricies varius nibh at aliquet. Mauris vehicula mi dapibus mauris tempus posuere. Vivamus dapibus condimentum nulla a vestibulum. Nam lorem arcu, vulputate sed varius vel.

Month Year<Title>

<Author>Stable URL: http://www.jstor.org/stable/xxxxxx

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci.

Month Year<Title>,

<Author>Stable URL: http://www.jstor.org/stable/xxxxxx

Month Year<Title>

<Author> Stable URL: http://www.jstor.org/stable/xxxxxx

<Subtitle>

<Subtitle>

<Subtitle>, <Author>, <Author>

1

4

3

7

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci.

Notes: List of Series/Sets (LOSS)

BLUE = BKS-89

1. Series Title is NOT clickable.

2. Coverage: span of years. Format will be YYYY-YYYY.

Computed based on the first published year of a volume in a series and the last published volume in a series.

Volumes: total number of volumes in the series: X Volumes

Publisher: name is clickable and goes to the Publisher page.

3. Books in Series:

The volumes are shown in the order of the published date, with the most recent first.

Each book may contain the following information:

Title: On click, goes to the book TOC.

Subtitle: OPTIONAL. If a subtitle does not exist, do not show an empty row.

Authors: Not clickable from this page

OPTIONAL: If more then one Author, they are separated by comma.

STABLE URL: Not clickable

Brief snippet: First 50 words of book blurb.

ORANGE = Separate Cards

4. Series Summary: X characters long.

If no summary, page content moves up.

This MAY be future content.

5. Access Key:BKS 91Should work as it currently does.

6. Access Icons: BKS-92Should work as it currently does.

7. Global Search: BKS-93Should work as it currently does.

2

6

5

, <Author>, <Author>

, <Author>, <Author>

J

B

J

J

J

J

1

Notes: This is first pass and the icons attached are not the final icons.

Success Criteria: An icon appears in the top right corner of each search result that indicates that it is a Book, Journal, or Pamphlet. These graphics should meet accessibility standards.

And  I  was  creating  what  I  will  call  JIT  wireframes.    Instead  of  trying  to  understand  the  entirety  of  the  functionality  of  the  work  upfront,  I  was  creating  very  discrete  artifacts  to  illustrate  stories.    

Learning  to  create  in  terms  of  “passes”  and  “not  perfect”     Pulls  dev  into  the  process  earlier

A N G E R

Anger  (I’ll  call  this  frustration)

The  Product  Team  experiences  a  lot  of  churn.    As  we  plan  sprints,  we  are  pulling  stories  out  of  the  backlog  that  we  had  an  understanding  of  “way  back  when”  but  may  have  lost  the  full  meaning  of  it  in  the  now.

This  feels  inefRicient  to  me.    If  we  had  written  things  down  more  completely  “way  back  when”  then  maybe  we  wouldn’t  have  to  spend  hours  trying  to  Rigure  out  what  that  sticky  mean.

Tension  with  the  dev  team.    It  turns  out  they  want  pixel  perfect  wireframes.    

A N G E R

Anger  (I’ll  call  this  frustration)

The  Product  Team  experiences  a  lot  of  churn.    As  we  plan  sprints,  we  are  pulling  stories  out  of  the  backlog  that  we  had  an  understanding  of  “way  back  when”  but  may  have  lost  the  full  meaning  of  it  in  the  now.

This  feels  inefRicient  to  me.    If  we  had  written  things  down  more  completely  “way  back  when”  then  maybe  we  wouldn’t  have  to  spend  hours  trying  to  Rigure  out  what  that  sticky  mean.

Tension  with  the  dev  team.    It  turns  out  they  want  pixel  perfect  wireframes.    

F R U S T R AT I O N

Anger  (I’ll  call  this  frustration)

The  Product  Team  experiences  a  lot  of  churn.    As  we  plan  sprints,  we  are  pulling  stories  out  of  the  backlog  that  we  had  an  understanding  of  “way  back  when”  but  may  have  lost  the  full  meaning  of  it  in  the  now.

This  feels  inefRicient  to  me.    If  we  had  written  things  down  more  completely  “way  back  when”  then  maybe  we  wouldn’t  have  to  spend  hours  trying  to  Rigure  out  what  that  sticky  mean.

Tension  with  the  dev  team.    It  turns  out  they  want  pixel  perfect  wireframes.    

B A R G A I N I N G

Bargaining  (Resigned)

With  each  sprint  review,  I’m  beginning  to  better  understand  what  the  developers  need  from  me.    And  we  

It  becomes  a  negotiation.    During  sprint  planning,  making  sure  my  deliverables  are  clearly  marked  up  and  expectations  are  set.    And  Rinding  a  common  language.    The  new  language  involves  stating  explicitly  this  is  a  “Rirst  pass”,  it  is  not  a  “perfect  representation  of  the  Rinal  product

B A R G A I N I N G

Bargaining  (Resigned)

With  each  sprint  review,  I’m  beginning  to  better  understand  what  the  developers  need  from  me.    And  we  

It  becomes  a  negotiation.    During  sprint  planning,  making  sure  my  deliverables  are  clearly  marked  up  and  expectations  are  set.    And  Rinding  a  common  language.    The  new  language  involves  stating  explicitly  this  is  a  “Rirst  pass”,  it  is  not  a  “perfect  representation  of  the  Rinal  product

R E S I G N E D

Bargaining  (Resigned)

With  each  sprint  review,  I’m  beginning  to  better  understand  what  the  developers  need  from  me.    And  we  

It  becomes  a  negotiation.    During  sprint  planning,  making  sure  my  deliverables  are  clearly  marked  up  and  expectations  are  set.    And  Rinding  a  common  language.    The  new  language  involves  stating  explicitly  this  is  a  “Rirst  pass”,  it  is  not  a  “perfect  representation  of  the  Rinal  product

While  the  product  team  sizes  the  story,  the  dev  team  writes  the  tasks  it  will  take  to  meet  the  speciRied  success  criteria.    If  the  story  involves  a  UX  component,  I  make  sure  the  team  understands  the  intended  functionality  and  as  many  of  the  rules  for  that  story.    And  sometimes,  they  know  more  than  I  do.    We  enter  a  collaboration.

Understanding  the  scope  of  the  “story”

And  I  am  with  the  team  throughout  the  entire  process.    I  don’t  work  on  deliverables  for  a  few  weeks  and  disappear.    I  only  recently  return  to  my  cube  to  work  on  my  deliverables.    I  work  in  the  colab  WITH  the  developers  and  the  Product  Team  in  an  open  collaboration  space.    

Insert  photo  of  colab  space.    Dev  team  and  product  team

D E P R E S S I O N

Things  are  going  well,  but  I  can’t  get  comfortable.    I  look  at  the  backlog  which  we  have  now  mapped  out  against  all  of  our  sprints.    

D E P R E S S I O N

Things  are  going  well,  but  I  can’t  get  comfortable.    I  look  at  the  backlog  which  we  have  now  mapped  out  against  all  of  our  sprints.    

W O R RY

Things  are  going  well,  but  I  can’t  get  comfortable.    I  look  at  the  backlog  which  we  have  now  mapped  out  against  all  of  our  sprints.    

I’m  anxious.    I  can’t  trust  in  this  process.      Looking  at  the  amount  of  work  we  have  to  do  with  NO  requirement  or  specs  is  making  me  nervous.    But  my  team  keeps  reassuring  me  that  we  don’t  need  that  documentation.    

Insert  backlog  breakdown  slide

A C C E P TA N C E

Acceptance

As  this  project  progressed  our  business  model  changed.    This  forced  a  change  in  the  requirements,  the  technology,  and  the  workRlow.    Assumptions  we  started  off  with  were  no  longer  correct.    With  each  change  I  began  to  realize  that  it  was  a  good  thing  that  I  hadn’t  spent  hours,  maybe  weeks,  deRining  something  that  no  longer  existed.    Rather  than  wasting  that  effort,  the  entire  team  was  able  to  adjust  and  course  correct  with  little  sunk  cost.

I  began  to  accept  that  this  process  was  working.

LESSONS LEARNED

Lessons  Learned

While  the  product  team  sizes  the  story,  the  dev  team  writes  the  tasks  it  will  take  to  meet  the  speciRied  success  criteria.    If  the  story  involves  a  UX  component,  I  make  sure  the  team  understands  the  intended  functionality  and  as  many  of  the  rules  for  that  story.    And  sometimes,  they  know  more  than  I  do.    We  enter  a  collaboration.

Understanding  the  scope  of  the  “story”

A  lot  of  work  isn’t  created  to  only  get  thrown  away

Pick  my  battles

Even  it  it’s  not  perfect  the  dev  team  still  looks  to  UX  for  direction  on  rules  and  edge  cases

UX  is  an  INTEGRAL  part  of  the  process  Liked  image

THANK YOU

QUESTIONS?

TONYA MCCARLEYMCCATO@GMAIL.COMTWITTER: TMCCARLEY