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.


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.


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.


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.


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.


  1. Some feedback for ya...

    this reads funny:
    "the message changing and changing hands multiple times."

    missing word:
    "...may as useful to you as it has been to us."

    "Is written over the Greek in the same wiki page."
    do you mean it replaces the Greek?  If so, that seems strange
    if not, then that seems like the finale is hard to read.

    where does Quality Assurance fit in? I just see 'developers' mentioned. Is QA a developer? I suggest not.

    also, it may be worth mentioning how long each roundtable is given or expected to take. and also when. meaning, when you go into sprint planning, is it a hard/fast rule that all stories be at the latin phase, english phase etc?

    I like that idea of blogging about this because every organization with a dev team struggles with this. and there is no "right" way, just like religion. find what works best for you.

    1. For the length Jay, I think it depends on the amount of developers. Simply because if you have 15 developers, you're going to plan more work than a 5-man developer team. I would say it depends on the best fit for your development team.

    2. Sprint frequency shouldn't depend on team size at all. Any case to make for longer sprints depend on other factors beyond the scope of this post. There is simply too much risk in longer sprints, and way too much room to hide inefficiency and waste to make a good case for it. Typically "Because it's hard" is a coward's excuse for not going with shorter sprints. That discomfort you feel when you try shorter sprints isn't a reason to stop, it's the reason you SHOULDN'T stop. That sensation is from all the fat in your process weighing you down convincing you that fast is too fast to be reasonable. Similarly, for some very unhealthy people walking rather than sitting seems unreasonable fast.

    3. There is also this to consider: http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

  2. Thanks Jay!
    Typos: I addressed the first two typos with an extra comma and word.
    Confusion: You may want to preserve your Greek by writing the Latin further down the page in your Rosetta Stone. For our Latin we're simply adding detail to the Greek framework which will remain largely unchanged. The overarching intent being to have the wiki page contain only two versions at a time that are easy to compare - The Hebrew (From the PO), and the Greek/Latin (From the Devs). By keeping it simple it also makes it easier for third parties like QA and other biz units to connect the dots conversationally between PO and dev expectations. Does that make sense?

    "Where does QA fit in?" - For now we're operating without a fulltime QA resource. Once we have one we anticipate a fifth translation into formal Gherkin. This may be another in-place edit of the Greek/Latin though, to preserve the simple before-and-after comparison on that wiki page for the epic.

    Roundtable - I'd have to give you a detailed rundown of our weekly sprint meeting schedule for you to have the whole picture, but the short answer is one hour. We despise long meetings, so ours rarely run over an hour. If you have two hours to cover, break it into two one hour meetings on two different days.

    "is it a hard/fast rule ...?":
    Here are some brief transitions requirements we use:
    - The Hebrew must be complete and coherent, written down by the PO before dev will begin work on the Greek doc.
    - The dev translating the Hebrew must complete a full translation of the Hebrew into dev speak (Greek) before the Latin can begin.
    - The Latin (detail/scheduling) phase must be complete to provide the biz with high level project delivery date outlines.
    - The PO must approve the Latin before the Latin tasks are entered as tickets in JIRA (English).
    - Lastly since we live and die by the agile tools for JIRA, the tickets for an epic must be entered into JIRA and organized for scheduling before dev will commit to any sprints containing tickets from that epic.

    This may smell like waterfall but it's not. For an epic of 4 to 8 1-week sprints worth of work we can fully translate an epic in just over a week with around 3 1-hour meetings worth of effort. That's while we're continuing to do our existing epic's work. It works very well so far. I'd love to get more feedback from you and the community on what's working for you and how it differs from this approach.

    1. Buy-in and discipline.
      The first requirement of all of this is that the entire organization must buy in to the strategy. If someone along the chain doesn't buy in, this strategy will fail or at best never reach its full velocity.
      What is all-to-common in the realities of established organizations (established in this context meaning those that have stakeholders outside of the founders), is that the market will 'demand' feature x, product will prioritize feature x and proclaim that it is a must-have-now addition to the company's offerings. Feature x is poorly described, poorly understood internally and rushed through the SDLC. Output? Typically its a majority of both tech and product debt which isnt visible until months or years down the road. Discipline of the process is paramount.
      A short sprint with a process that churns through the biblical metaphors quickly, is key to success. The longer the sprint, the more rigorous the process, the easier it is to deviate.