Large Agile Estimation Scenario: Pure Ideal Days | Jesse Fewell Large Agile Estimation Scenario: Pure Ideal Days – Jesse Fewell

Large Agile Estimation Scenario: Pure Ideal Days

By July 29, 2013Blog, Uncategorized

In our previous entry, we looked at the happy path approach for using story points to estimate how much work will fit into the upcoming quarterly release for our fictional product group. Now for the approach of “Ideal Days”.

Context: The prelude to the story plays out the same as in our last episode. We have four agile teams with known, stable velocities for each of the teams, supported by a cross-functional Product Ownership Team.  First, the Product Owners have been working with their respective teams to decompose the high-level goals for the upcoming quarter. These conversations happen with regular grooming meetings that happen during the iteration.  Finally, a day or two before the beginning of the next release cycle, the group all comes together to plan out what should reasonably be doable for the upcoming quarter.  The Chief Product Owner reveals the preliminary estimates provided by the team so far, “The total forecasted work is 808 Ideal Days, which fits nicely within our forecasted velocity of 838 Ideal Days this quarter. So, I should be able to announce to investors tomorrow that we will deliver these initiatives this quarter, correct?”

ideal-days-example

Immediately, some people in the room begin to highlight the fact that the average hides the variation. Some quick rejiggering of the math down to the team level, we see that the teams are unequally loaded. What do we do?

ideal-days-imbalance

A Word about Agile Resource Leveling.   Many of you project and program managers will recognize this problem instantly as that of “imbalanced resource loading” or resource overallocation. This is a huge discovery for the Product Owner. In fact,

A key reason for estimating work, is to discover throughput constraints, before the work begins.

Team Delta looks to be pretty critical for all 3 initiatives. They represent a constraint to the flow of work through our organization. Isn’t it great that we know this now, instead of a couple weeks before the target release date?

Release Planning for Resource Imbalance. After the teams object loudly about the imbalance, the Chief Product Owner says “It is absolutely critical that we get at least these the top two initiatives done. If we don’t get those to market in the next three months, we can all kiss our jobs goodbye.” The teams then go into break-out sessions with their product owners and begin to treat the 3-iteration mandate as a budget. To do that there are two sides to the equation:

  • “Hey Product Owner, which of these user stories could we live without, in order to meet the 3-iteration mandate?” : Often Product Owners will over-interpret strategic goals, and invent special cases that rarely occur.
  • “Hey Dev Team, which of these user stories could benefit from a lighter-weight implementation, in order to meet the 3-iteration mandate?” : Often development teams will desire to build a requirement using the hip, hot new technical approach, when in fact an older more nuts-and-bolts approach is just fine, and a lot cheaper. To be clear, I’m not talking about cutting corners, but rather deferring the construction of a TARDIS when a calendar could do the same job.

How to keep it Agile. Before you start saying this kind of release planning is anti-agile, here are some tips to keep from falling back into traditional project management. First, our estimates should be used to plan for 1-3 months out ONLY. Once we extend beyond a quarter, our detailed planning starts to fall into the dangers of big-up-front-planning territory. Second, Here, our release plans remain a plan, not a commitment. We may commit to the content of the upcoming iteration, but we reserve the right to make changes between every iteration if need be.

For near-term planning, Story Points or Ideal Days behave the same. Here’s another observation. Many people want to estimate in Ideal Days, because they believe this kind of constraint is harder to find when using Story Points. However, taking a quick look at the Story Point example in our previous post, we see the same issue: The workload looks fine in the average, but looking at the details reveals a good old fashioned critical path. There are some aspects of what an agile release leveling would look like, but I’m going to save that for a later post. Instead, I want to focus on the key point:

Whether you use Story Points or Ideal Days, the math is the same.

Here are some patterns:

  • [As with story points, pay Attention to Velocity]. Do not simply assume that a team with 60 mandays in an iteration will automatically deliver 30 ideal days of estimated output. As with story points, pay attention to actual velocity.
  • [As with story points, use holistic numbers]. Sure, you need to add up the tech writer Ideal Days + engineer Ideal Days + tester Ideal Days to find out that Gamma’s contribution to performance improvement is 59 total ideals days for the whole team. But once you add them up, dispense with those granular details and manage to the whole-team number, just as you would with story points. Otherwise, you prevent the kind of whole-team accountability that make agile teams more productive.
  • [As with story points, ask the whole team]. In our example, both the Product Owners and the Dev Teams must work together to forecast a plan for a very firm goal. If management unilaterally decrees exactly WHAT will get done within 59 ideal days, then the teams will succumb to the pressure and tell you want you want to hear.

 

 

What about you? Have you found some teams are more overloaded than others? What have been the similarities or differences using Ideal Days or Story Points to estimate work?