Estimating Relative Complexity
Reasonably accurate estimation of user stories is necessary in order to provide the customer with development schedule predictability. Small stories are usually fairly easy to estimate, but estimates for larger stories are often accompanied by higher degrees of uncertainty. Although a large story may sometimes be broken down into smaller stories for purposes of estimation, this is not always the case.
This workshop proposes a method for enabling a team of developers to rapidly quantify the relative complexities of larger user stories by using “tests” as the unit of estimation.
This session is intended to be a highly interactive workshop and discovery session, the purpose of which is to demonstrate a rapid method of estimation that leverages the skills of every team member to arrive at estimates for medium to large user stories.
I’ll begin the session by reviewing why we make estimates in the first place, emphasizing that the purpose of estimating is chiefly to provide the customer with development schedule predictability. I’ll also engage the group in a brief discussion on the merits of estimating using relative units (such as story points) rather than absolute ones (hours or days), touching on the meaning of the term “complexity”.
Once this foundation has been laid, I’ll point out that most developers are probably already employing an agile practice which, if looked at differently, provides an indication of the relative complexity of stories already developed, namely test-driven development (TDD). Since more complex stories should be supported by greater numbers of unit tests, we can imagine that determining the approximate number of tests ahead of time would give us the relative complexities of a set of stories for estimation purposes.
The trick, then, is to be able to determine how many tests might be required to support a particular story.
At this point, I’ll ask the attendees to divide up into teams of from 3 to 6 people each. Each team will be assigned the task of coming up with relative estimates for a small set of stories from a fictitious product.
In the first phase of estimating any given story, all team members will write down on large Post-It Notes as many “test titles” as they can imagine, as quickly as they can, and place them on a section of wall. This phase will be limited to about 5 minutes.
In the next phase (also about 5 minutes long), each team will use “cluster mapping” to group together redundant or similar tests, arriving at a single test count for the story.
This process will be repeated for all stories in the set. The result is a set of estimates indicating the relative complexity of the stories.
Once all stories have been estimated by all teams, we’ll have a look at both the absolute figures (test counts) produced by all teams, as well as the placement of the stories in order of relative complexity. Correlations will be drawn where they exist.
In summary, we’ll discuss how estimates whose units are “test count” might be mapped to the more standard estimates in unitless “story points”.