Make estimating easier

Break your sprint planning down.

Do you need to estimate the individual tasks? I've done sprint planning two ways:

1. Stories are estimated in story points and then tasks are estimated in hours
2. Stories are estimated in story points and tasks simply fall under that with no estimate

Of the two, I prefer the second option. I find that not estimating tasks gives more freedom to developers to cope with changes. If a task no longer makes sense (how many times have you found out that a task isn't applicable or was already done in a previous sprint) you simply throw it out without any penalty, or you may have to change a current task into something new, possibly breaking it up. You're really being redundant if you estimate both, as the sum of the tasks should represent the story points and vice versa. What value do you really gain by this other than knowing how much time individual tasks will take? If you find yourself with task sizes that really vary enough to make a difference, I would suggest breaking those tasks down into smaller, more homogeneous chunks.

By doing this, you can cut down on the time you spend in sprint planning. Stories get estimated during sprint planning, and when you start the sprint you can put down all the tasks you can think of that make up that story. Obviously if there are points that you come across in estimating the story that you know will have to be dealt with in a task, you can add that onto the story information and put it as a task.

Estimate in Ideal units

Story points are meant to be in ideal units such as ideal man hours or ideal work days. These are meant to mean that given the perfect day every day, where you had no interruptions, no meetings, and everything went according to plan, you could accomplish the task in X days. Now everyone knows that this simply isn't true, but the wonderful thing about statistics is that it doesn't have to be.

What I mean by this is that after a while of estimating these in ideal days, you realize that maybe it takes an extra 25% of the time you estimate on average to complete a story. Lets say you had estimated 4 ideal work days, and instead it took you 5. Over time, you keep track of this and then you have a rough idea of the conversion from ideal days to real days. Your first instinct would be to try and compensate for this by over estimating, and you would likely be wrong. The main thing here is to stay consistent. That way, your long term average remains the same. Sure sometimes, it'll be under and sometimes it'll be over, but the more you estimate, the better off you are. If you find that you still can't get a decent estimate, maybe that means you don't know enough about the story to estimate it properly.

Talk about the stories

When you estimate, everyone should have a rough idea of what will need to be done, from start to finish, of what it will take for this story to be complete. You don't need to know every detail, but enough that you think you, yourself, could undertake the story. If you don't have that level of confidence, you probably shouldn't be estimating it. If you say "Well this story is too big for us to know most of the details" then that's an indication that the story is too big, and should be broken down. Stories, at least in my experience, have been small enough that one person, if need be, could work on it alone and accomplish it within a week or two.

This also will help to solve your second point in the edit, which is too much estimation. Instead of estimating every single task for every single story, you simply estimate the story as a whole, which should help to remove a lot of the estimating. As for making the meetings less monotonous, I would suggest planning poker, which you can see more information about above.

Make planning more engaging

Estimate using Planning Poker

As far as making estimation more fun, have you tried planning poker? It's the way that I've always done planning for all my sprints on multiple teams, and it's a good way to keep everyone involved, as every person has to at least pick SOMETHING. There's also a fair amount of fun involved when everyone on the team picks 3, and someone puts down a 20 and has to explain themselves, or when everyone on the team puts down a 5 but the manager puts down an 8 (who's gonna argue with the boss when he wants to give you more time!).

To do this, all you need are some planning poker cards, which we often make on the back side of index cards, or using normal playing cards with values attached to face cards. Nothing fancy, and it keeps everyone focused. Just remember that trying to do any task for an entire day (including planning poker) takes a toll on productivity. Many sets of cards come with a coffee card for a reason; if someone is feeling burnt out, give the team a break to recharge and pick it up when everyone is fresh!

As an alternative to physical cards, you could also look at electronic cards. The real benefits here are automated tracking of results, tracking user stories to be estimated and allowing everyone to show their cards at once to avoid "cheating" (where one persons estimate is influenced by another's due to being able to see their card). Obviously this requires everyone have a computer and the ability to focus on the task at hand though, so use it at your own discretion.

This is not dissimilar to how we run some of our scrum process. We

1. Estimate stories near the top of the backlog in "story points"
2. Select/explain stories based on the story points that we think will "make up" the sprint
3. Break down the stories into more detailed technical tasks
4. Estimate the technical tasks and compare with the original story points estimate (we know approximately how much development time a story point normally equates to)

But what you want to know is why we estimate twice!

• We do a coarse estimate (based on the story) because we like to be able to make predictions about what might be in the next sprint, and maybe even the one after that. Ultimately management have to be able to communicate with the customer about likely time-scales, so if we don't have this coarse scale estimation then long term planning is virtually impossible.
• Obviously, this means we do coarse estimates for more than just the current sprint. Because there's no guarantee the backlog order won't change for the next sprint we don't want to invest the time in doing task breakdowns and fine-scale estimates until they're necessary.
• We break down the task to make sure that all the tasks have been enumerated and that stories can be worked on in parallel more easily.
• We do fine-scale estimates (based on the task) because this gives us a much smoother burn-down graph (particularly where there's no easy way to break a large story apart into viable "features").
• Because we do both, they act as sanity checks on one another - a wild discrepancy indicates we need a mistake somewhere that we need to identify. This is a useful by-product, but not the reason in itself why we estimate "twice".

Rereading your question and comment, I see there are some differences between our workflow and yours.

• We do breakdowns as a team, we find although the overhead is greater the technical discussion we get from this is often very valuable and can detect shortcomings in our story. When we have experience, knowledge or ability disparity this discussion is also where those with more can help out those with less (very useful with new hires).
• We do estimates at the task level as a team, one of the reasons why "planning poker" works is because of the "wisdom of crowds" phenomenon - as I mention in comments, by this point estimating a task should take less than 30 seconds, so the overhead is negligible.

It sounds like the reason your team does task breakdowns and task estimates is for a smooth burn-down - which is fine, that's all part of monitoring the progress of the sprint and allowing your scrum-master to detect and resolve issues early. If you want this information you have to do the breakdowns and estimates and you have to do them first.

In my opinion task switching is not likely to be a problem for you here, I don't think that breaking down different tasks is really a task switch in the same sense that flipping from developing one feature to another part way through is a task switch. I think gaining an understanding of the overall "architecture" of the sprint is probably quite a useful thing.

However, I think there may be some other problems you could consider. As always with agile you should identify a problem you have and propose a solution, then decide if your solution worked in the retrospective. This is the crux of building an agile solution that works for your company and your team. So, some problems you might have:

• You're doing breakdowns individually - so how are your junior/inexperienced team members learning from your senior team members? Sure, they can probably learn everything themselves - but they'll learn faster if they're mentored. Are junior team members taking a long time to break things down? Are they making mistakes or missing things that cost the team time in the long run? Breaking down as a team can help here.
• You're doing estimates individually - the same applies as the first point, but in addition are these estimates less accurate than they could be?
• It sounds like tasks are assigned at the start of the sprint, but if this is the case then how expensive are you finding it when you have to change the assignment? If someone is falling behind or ill, how easy is it for someone else to pick-up their tasks? Do they have to go through the task breakdowns and try to understand them without interrupting the original assignee? If you breakdown and estimate as a team then everyone should be able to work on everything!
• Are your stories too big? If the break down takes 50% of the time, the stories sound like they're very involved - perhaps they can be made smaller? We keep our stories within 1 man week of work.
• Are your tasks too small? If you're spending a long time making task lists maybe you're going into too much detail? We tend to have tasks between 1 and 8 man hours worth of work so that over the course of a day everyone makes some progress to report at the next daily standup.