We can greatly simplify estimation through a three bears approach; too small, too big, or just right.

User Stories

There is nothing that intrinsically limits user stories to be under a certain size. If it is a true user story, written by a user or a proxy they can be any size. However, if you are using Scrum or other approaches with time boxing, user stories lasting more than a couple of weeks can't be practically completed.

There is really no good solution to the story which is 'too big'. If you ask users to break it down you are potentially asking them to determine what the solution looks like. Stories might require effort from multiple developers across multiple specialties. This results in stories being broken down into tasks. The difficulty is that tasks are irrelevant to the user.

Ideally we need to encourage users to write user stories that are in this magical middle ground of not being detailed specifications but still being granular and small enough that they can be completed within a sprint.

Otherwise we can end up in a silly situation where a single story contains a large number of tasks, and the story itself travels from sprint to sprint never being completed.

Story Estimation

If you are following Scrum you will estimate stories during the Sprint Planning Meeting. The teams I've been involved with might vary the process, such as splitting the meetings between a engineering meeting to estimate stories and a user meeting to set priorities, but you end up in the same place, making the same estimations.

It is common to use T-shirt Sizes or the Fibonacci Sequence in estimation. The idea is not to tie estimations to specific units making absolute predictions about the time to complete them. This is a little disingenuous as we need to have some consistent concept of what these sizes actually mean in terms of effort.

In practice I see three broad categories used. The first is trivial; where the change is so small it almost isn't worth tracking. The second is mainstream stories, where the effort is between a couple of days and a couple of weeks. Finally there are the stories which are bigger than a sprint, which are usually assigned large estimates to signal they need to be broken down into something that can fit in a sprint.

Burndown graphs and estimates

After Spring Planning your Scrum Master might track the burn down each day in standup. The burndown graph might be presented based on the original estimates of the stories. Thus a story that was estimated as a 7 would be 'worth more' than a story that was a 1.

There is a risk that estimations turn into commitments. There is also a danger that management will ask you to 'update' a story with time remaining based on work to date. This is worthless and time consuming with no benefit at all. Either the story is complete or it isn't. You can no more say after one day whether it is half way or one quarter done because you can't see the future. In my experience it is more valuable to show the burndown of completed stories.

This can be scary for managers who would like to see a steady linear progression toward completion. There is a total absence of completed stories for days, perhaps even a week, followed by a influx of completed stories toward the end. But if you think about it this is exactly what you should expect.

Three Bears Estimation

I'll go back for a moment to the idea that stories are too small, too big or just right. Stories that are too small should just be done without tracking. Examples of these include changing the text of a label for example. One or two of these in a sprint is no big deal, but if users are submitting stories that are too granular the effort tracking them just isn't worth it, making planning harder and dramatically increasing development process overhead.

Stories which are too big need to be reworked somehow to be small enough that they can be completed in a reasonable time frame. This is sometimes easier said than done, but from a practical sprint planning point of view there isn't much of a way around it.

This leaves us with stories which are 'just right', which are on average the same size. In effect they can now be considered one size.

By removing estimations from stories in progress we remove the 'permission' for one story to take longer than others. Conversely we remove the guilt and anxiety in the event a small story blows out.

What we care about

Delivery. In a word. Users don't care about tasks completed, they care about stories delivered. Data about how long stories take on average is brutally more objective than any estimate.

Once you know how long the average 'just right' story takes to complete you can begin to provide reasonable broad estimations of effort back to the business when planning projects, assuming they can break a project into user stories of this size.

Reward delivery over estimation accuracy. We are paid to deliver functionality, not be magical seers.