Rostetta-Stone-182x182Estimating.  The glory.  The pain.  The never-ending challenge.

Before you think to yourself, “we’ve heard this all before” and close your browser, this short article is absolutely not going to go into the depths of each technique, whether it be planning-poker, min-max-most likely, relative, man-day or t-shirt sizing but rather ask you to think about something that may make planning, at a high-level easier and more straight-forward and incorporates man-day effort, relative sizing and planning-poker, all at the same time.

The only pre-requisite, is that you and your team can identify a “Rosetta-Stone” that just happened to be the effort-size of one of your time boxes’ capacity.

What is the Rosetta Stone?

The actual Rosette Stone (pictured above) is in the British Museum in London, England.  Wikipedia introduces it as:

The Rosetta Stone is an ancient Egyptian granodiorite stele inscribed with a decree issued at Memphis in 196 BC on behalf of King Ptolemy V. The decree appears in three scripts: the upper text is Ancient Egyptian hieroglyphs, the middle portion Demotic script, and the lowest Ancient Greek. Because it presents essentially the same text in all three scripts (with some minor differences between them), it provided the key to the modern understanding of Egyptian hieroglyphs.”
When planning a release or a project that will use Agile Project Management techniques, an initial set of workshops is required to plan out the activities across the timeboxes.  In order to do that the ‘size’ of each piece as well as the priority needs to be agreed.  This is top-down planning in its simplest form.

 

 

Only later as each team starts each timebox will they provide the bottom-up estimates that they will commit too.  Of course these could affect the overall plan and the process to handle this eventuality will be explored later in the article.

For now however, we need to focus on what we want each team to work on in each timebox in the release / project.  To do this, we need to have a relatively good understanding and agreement on the size of a piece of work.  This is where the “Rosetta Stone” concept comes in.

What is Rosetta Stone Concept?

This is the name we gave to a process that helped us at one client.  During a planning workshop, which is normal practice in Agile methods such as DSDM Atern or Agile Project Management, a group of us were trying to understand the size of client request.  We then recognised that it was similar to a piece of work that a team did a few months ago.  That piece just so happened to take 54 days.

This was exactly in the sweet-spot of our Agile team’s capacity, as explained below:

When 5 people work 5 days a week for 3 weeks it provides a maximum capacity of 75 man days.

Assume a productivity rate of 60-75% (45-56 days) we can assume that they should be delivering 50-60 days of effort. Yet in the big picture view, in order of magnitude, and with Agile teams gaining better productivity, we felt comfortable to say that this new piece of work was about one timebox of effort for one team.  54 days was in the range of 45-56 days.

What is important to realize and perhaps what is key, is that the exact days are not the issue, but rather the assurance that it ‘feels’ right.

We then realised that we could use planning poker to ask “is a user-story smaller than our Rosetta Stone e.g. ½ or ¼ or three times larger”.   If it was larger than 3x we knew we had to investigate further in order to split it into smaller chunks to reduce risk.

So, we could use planning poker to produce relative estimates and we could translate those ultimately into man-days but better we could very quickly build a plan for the release.  Unlike the Rosetta Stone which helped unlock our understanding of an ancient language, this concept helped us on six points:

  1. We could make use of team-based planning poker.
  2. We could realise the benefits of relative estimating.
  3. Sizing by timebox kept people at the right level of detail.
  4. Easier high-level project & release planning.
  5. Easier high-level capacity planning.
  6. Easier co-ordination with financial planning and budgeting.

Then, as the teams started to work according to the plan, they spent the first few days of each time box (which is standard practice) really understanding the user-stories and providing feedback through their commitments and any large differences could be taken into account and the high-level plan adjusted if necessary with, in the worst case scenario, lower priority items dropping out of scope as “wont’s”.