Tuesday, November 20, 2012

Translating an Epic

What do the story of Gilgamesh, the Iliad, and the Mahābhārata have in common with your project document?  They are epics that have been translated through multiple ‘languages’ and been touched by many hands during translation.  I point out these similarities because we have found the metaphor of translation of historical epics useful in describing the various stages that our own project epics undergo as they are translated.  

Your next project document is no different.

In scrum-speak user stories are the single sentence descriptions product owners (POs) use to describe their needs.  Since we refer to these descriptions as stories it is natural that we call large collections of these stories epics.  POs write the epics and pass them to the dev team in some fashion, the message changing, and changing hands multiple times.  Multiple teams.  Multiple people.  Multiple translations.  

I say ‘translations’ because intentions are easily miscommunicated and when combined with the differences in how biz and dev describe the world it can often feel like we’re speaking completely different languages.  In considering how to manage these translations we explored a number of metaphors.  It needed to convey the importance of the POs original request while providing enough layers of translation to contain all the times the message would change hands.  After considering and discarding several we settled on the Biblical.  I present this to you in the hope that it or some variation may be as useful to you as it has been for us.  


As you read this keep in mind that we use one-week sprints and the Atlassian On-Demand tools.

HEBREW

The raw original epic from the PO.  It has no estimates. It could very possibly make no sense.  But it does convey intent and intends to paint a picture of how users will interact with new/updated features.

  • Written by the PO.
  • Can be delivered through any channel (word doc, wiki, etc), but must be committed to the wiki in it's own epic page before the Greek translation can begin.
  • May include prototypes or flowcharts that live elsewhere, including the backs of napkins.


GREEK

The first translation digestible by developers translated by developers from the original Hebrew.  It is much more coherent and sprint friendly than the Hebrew.

  • Written by a developer.
  • Is probably in the proper story format, but...
  • Stories may not be small enough to fit in a sprint.
  • Lives in the wiki.
  • Is written after the Hebrew on the same wiki page.


LATIN

An in-place translation of the Greek which is sufficiently granular and organized to determine the delivery date for the epic

  • Written collaboratively by the developers.
  • Is written over the Greek in the same wiki page.
  • Contains only stories that are small enough to fit in a sprint.
  • Lives in the wiki.
  • Finalizing the Latin involves a dev team round table.  Prior to this round table, each member separately writes estimates for each story in the Greek, if necessary breaking stories down into 3-day or smaller stories in the process.  At the round table, the different breakdowns and time estimates are reconciled.  In general the longest estimate wins.
  • Estimate totals are used to determine a delivery date based on 4 development days (32 development hours) per developer per 5-day work week.
  • The final result of this effort is to be confirmed by the PO as still representative of the original intent.


ENGLISH

The first official translation that ends up in Jira.  It's in the proper format. It's actionable.  It includes test criteria. It has been approved by the PO.

  • Written by a developer.
  • Is written/created in JIRA.
  • Each story from the Latin is a story type ticket in JIRA.
  • Tickets are labeled with a version number or name of the epic.
  • No ticket may have an estimate longer than 3 days (given one week sprints).
  • If a ticket/story estimate ends up longer than 3 days the story must be broken down into two or more stories.
  • Tickets are grouped by upcoming sprints to uncover any problems with the deadline determined by the Latin translation.
  • Story acceptance criteria are not required until the Sprint Commit meeting and should be written by the team during the Sprint Prep meetings.

This works well for us. YMMV.  This is intended to spark discussion.  I’m interested to see what the rest of you out there are doing and how this maps to what you already have in place. Hit me up and let me know.