Agile – Why Higher Story Points Represent Exponentially More Effort

Ideally, your software should be bug-free after each iteration, and fixing bugs should be part of each sprint, so the work required to fix bugs should be considered when assigning story points (i.e., a task that is more likely to produce bugs should have more story points assigned to it).

In reality, however, bugs surface post-deployment all the time, no matter how rigid your testing; when that happens, removing the bug is just another change, a feature if you will. There is no fundamental difference between a bug report and a feature request in this context: in both cases, the application shows a certain behavior, and the user (or some other stakeholder) would like to see it changed.

From a business perspective, bugfixes and features are also the same, really: either you do it (scenario B), or you don't (scenario A); both scenarios have costs and benefits attached, and a decent business person will just weigh them up and go with whatever earns them more profit (long-term or short-term depending on business strategy).

So yes, by all means, assign story points to bugs. How else are you going to prioritize bugs vs. features, and bugs against bugs? You need some measure of development effort for both, and it better be comparable.

The biggest problem with this is that bugfixes are often harder to estimate: 90% or more of the actual effort lies in finding the cause; once you have found it, you can come up with an accurate estimate, but it is almost impossible to judge how long the search will take. I've even seen a fair share of bugs where most of the time was spent just trying to reproduce the bug. On the other hand, depending on the nature of the bug, it is often possible to narrow down the search with some minimal research before making an estimate.

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.