Two Oversimplified, Yet Effective Agile Estimating Models?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As with all things software and agile, every topic can bring complexity and depth to what would otherwise seem a straightforward topic. Such is the case with the question: “Now that my teams are agile, how can I estimate how much work we can do in an iteration?”
In general, the estimating process is simpler in agile, in that teams typically need estimate only a short amount of upcoming work, typically an iteration or two. Plus, they have small estimatable stories as raw currency, and they have their historical story velocity to count on, providing greater fidelity in future work. However, even then we often approach the questions of “How long would it take us to do Feature A”, where Feature A may be too big to fit in an iteration or two, and yet it is too early to provide a detailed estimate or story elaboration or research spikes needed for same. Moreover, if Feature A is a really big deal, and Feature B is easier, the product owner might switch to the customer/cost benefit value of Feature B, so it behooves the team to be able to provide gross level estimates of various features without too much investment in the estimate itself.
I’ve seen agile teams take a variety of approaches to this problem, including these two:
1) Ideal Developer Days. With the ideal developer days approach (IID), the team estimates how many “ideal” (non-interrupted, vacation- and illness-free) developer days it would take to accomplish a feature. This ignores the realities of the non-development activities of the Define/Build/Test component team, but since a) the development of new code can and should be the bottleneck in most teams, b) the team is used to bidding stories in units of days or fractions of days, the teams at least have a currency with which to bid new features. Since the team likely has history that shows how their estimates track actuals, and the team can readily calculate how many IDD there are in an iteration (number of days in iteration times the number of developers on the team), this simple estimate can be used to understand “about how long” it would take to deliver a feature. Product owners then can prioritize the backlog and have a reasonable expectation as to about when they should see Feature A.
2) The “Student-Body Left-Shift Number-of-Iterations” Heuristic. I’ve seen an even grosser, yet somewhat effective estimating heuristic applied as well. In this model, the teams ask themselves the question “If everybody on the team worked only on this feature, how many iterations would it take us to complete it?” This may seem a silly heuristic on the surface, and yet since a) agile teams implement stories/features serially, and b) the organizational models of shared code ownership, team rotation, and “everybody tests” creates a physical model whereby it is indeed quite practical for a team to “swarm” a story or feature in an iteration, this heuristic is not so silly as it might seem. Moreover, the answers are small numbers that are easy for a Product Owner to work with, as typical answers for non-trivial features run in fractions or small numbers of iterations. (ex: 1/2, 2 or 3).
This model has the additional benefit of making Release Planning easier, as the feature/iteration estimates sum nicely to predict what features can be accomplished a release or so out.