Estimations are used by agile teams and product owners for prioritizing work and to plan releases of products. They can be done on different levels and in various ways.
In his blog post long-range planning with user stories George Dinwiddie shares ideas on prediction using agile. He explains that user stories can help teams to get things done, but planning a release with user stories only can be too much effort to be workable for a team:
If a three-month (13 weeks of 5 days) release is broken into User Stories that take two team-days each, then that’s about 32 stories. That’s a lot of stories, but it’s more if multiple stories are in-progress simultaneously, or if some of the stories are smaller. If half the team gets involved in each story, and half of the stories are only one day, then our story count balloons to 96. Imagine the team churning through a list of 96 stories at the start of the project so that we can know what fits into three months, or that we can know how long it will take to do what we want. Sounds like a lot of effort, doesn’t it? (And this is for a small project.)
George suggests to in stead use features to do estimation for releases:
I would list the features (which some people call big stories, or epics) that were known, sort them into piles of approximate perceived size, and estimate those perceived sizes as best I could with whatever historical experience I had. Then I could test those perceptions when implementing the first of those features and adjust my expectations to the empirical results. As things proceeded, I could continue to refine my expectations. I could also readily change my mind about what features were really needed, or how much effort to put into a feature, because I hadn’t invested a lot of energy into it, yet.
Why is it so difficult to do estimations and what can you do to make it easier? George gives some advice on this:
Estimating big chunks of work, like features, is different from estimating small chunks of work, like User Stories. We, as a species, seem poor at giving consistent estimates over a broad range of sizes. I’ve never known the sum of estimates for User Stories to implement a feature to bear much relationship to the estimate of the feature. For that reason, I suggest treating them separately. I typically use T-shirt sizes for features, since so little is known about them that numerical estimates always seem unduly precise. For User Stories, I prefer to just count them. Yes, they are different sizes. They should not be such a broad range of sizes that it matters much, though. And in my experience, it’s easier to get them to similar sizes by examining the acceptance scenarios needed to verify them than to estimate them with numerical consistency.
Mike Cohn wrote the blog post assigning story points at the right time—or not at all. According to him there are two reasons for estimating the product backlog:
First, estimating product backlog items allows the product owner to prioritize the product backlog. An estimate represents the cost of an item. Without knowing the cost of an item, a product owner cannot successfully prioritize.
The second reason to estimate is so long-term projections can be made about the project. If a boss, client, or customer wants to know when a team will finish a set of product backlog items, those product backlog items need to be estimated. Similarly, if a boss, client, or customer wants to know how much can be delivered in three months, approximately three months worth of items need to be estimated.
Doing the estimations in the planning game is too late, says Mike:
Knowing the reasons why to estimate product backlog items can also help fix a very common problem I'm seeing more often: Estimating the product backlog at the right time. The product backlog needs to be estimated early enough that the product owner can either prioritize or answer the above questions about when or how much will be delivered.
Putting story points on product backlog items during sprint planning is simply too late for those benefits to accrue. There are other problems with assigning story points during sprint planning but assigning them that late does not allow the product owner to take advantage of the new information in time for the sprint being planned.
In the ACM article user stories don’t help users William Hudson states a problem he sees when the release planning is only based on user stories:
In XP, user stories are meant to feed into the planning game (…). But if a team is going to make estimates and plans based on user stories, they need to at least know what needs to be done and approximately how. This is particularly true of novel systems, where there are no established current practices to be described. That means we need to give some thought to the purpose, shape, and size of the system before writing user stories. Unfortunately, many Agile adopters believe that design is a bad thing, even though this is not actually what the Agile Manifesto and its “Twelve Principles of Agile Software” say (“big design” up front is bad, but rough design is not). So, not surprisingly, estimates and plans made with premature user stories may not be very reliable.
Steve Povilaitis wrote about how to manage large agile enterprise programs with features. He explains some of the benefits that you can get from using features in release planning:
Features are needed to scale, because it’s too difficult to manage large programs with just user stories. Release planning becomes too detailed if you don’t have a middle tier of features representing what you’re trying to build. Without features you lose the ability to coordinate across teams effectively and are not able to provide enough context about the higher level value and goals. You need features to define the product, coordinate, and plan what you’re going to build at the delivery team level.
Michael Carew wrote a blog post agile estimating – if the T-shirt fits . . . in which he talks about estimation for themes, epics and user stories. In the early discovery phase Michael suggests two possible approaches. One is to estimate with T-shirt sizes, another way is to estimate using so called Agile Development Units:
An [Agile Development Unit (ADU)] is a scrum team for one sprint, with support. This is used to begin to understand the amount of resource that will be required. In some cases ADUs are bought, and then work can be tailored to fit, a form of cutting your coat according to your cloth.
Estimates either based upon T-shirt sizes or ADU’s tell us something about the size of the work and not about duration. These estimates are used in business decisions during the release planning:
At this point we have an estimate that is not based on a great deal of inspection, but is about relative sizing to previous experience. This allows us to update release plans with the latest estimated work. Based on the priority assigned by the business through the product owner, we can now start elaborating the themes and epics into user stories.
User stories are estimated with story points. Michael suggests to check these estimates against the earlier estimates, for instance by using a table of T-shirt sizes and story point sizes:
They should be examined to see if there are any unexpected relationships between the various estimates for a story. This means a misunderstanding is present. (…) Identifying misunderstandings at this level it means looking to see if the business sized a story as “S” and the grooming sized it as “15.” This indicates that we have a difference in understanding. The next step is to discuss it.
The last step for the team is to estimate in hours:
During sprint planning we now move from story points to hours, and determine if we are using real or ideal hours. Typically a team will estimate in ideal hours and then translate to real hours using a conversion factor. To calculate this factor we should measure the planned hours against the real hours as the sprints progress.
How do you do your estimations for release planning?