Do you estimate bugs that are added before you add them to a sprint?

[Ivar]

Hi all!

I am wondering how you deal with bugs during a sprint in regards to estimation (with Jira Agile and Rapid Boards).

Assuming you register each bug when they are found during the sprint (as we do) - do you estimate them before you add them to the sprint (e.g. issue is not DONE before the bug is fixed), or do you just add them to the sprint without any estimates, assuming they are "small enough to manage within the scope"?

Or do you estimate them, leaving out the ones that are estimated to "to big for this sprint" or reducing the scope by removing other planned stories?

[Edit] - And if you estimate them during the sprint. Do you estimate them in story points (they are on issue level, same as user stories), or do you estimate them in hours?

If you do not register bugs found on the functionality implemented during the sprint - how do you do this?

[Ivar · Accepted solution]

We will most likely end up with the following change:

All issues found during sprint are created as bugs, and assigned to dev once found (or actually, when QA is done with the test of the particular issue). These bugs are not estimated as a change to our DoD require all work to be completed, including bugs like this. SO in practice, the work needed to kill of the bugs should be considered a part of the estimate of the original story.

Bugs found that are not explicitly linked to the current sprint is estimated like normal issues and planned accordingly.

[martin.mctighe]

Hi there Ivar,

This is all in my opinion, I'm by no means an Agile guru but.....

My Team don't use hours at all, we only use story points. This way it is kind of expected that a large point task is a less reliable estimate. The act of matching story points to hours directly is a dangerous one and potentially neglects the point of story points in the first place (there is probably some good stuff on the net about this, google is your friend).

Story points conversion to time relies more on having a history of how the team performs. After a few sprints you could estimate that your team could "Commit" to finishing 10 points of work reliably. This importantly doesn't mean you can't do more work but that, given no changes in priority, you will get these tasks done.

You will find that you are not 100% accurate to the hour on points estimates, this is why they are estimates. The way the commitment works is that you would commit to finishing less than you normally finish - your commitment being that if you had to ship next week, here is a list of what WILL be in - then take in any extra work you want so people are busy but always prioritise helping the people doing the tasks that are committed to.

Regarding Jira Agile (formerly Greenhopper) some of the things I like with it are (and do note that nothing in Jira Agile can't be done on a whiteboard, it's just easier):-

* Historic Velocity tracking with committed and completed work - you can see if you are reliably over-committing to a sprint.

* Sprint burndown charts, let you know when to pull the panic lever

* Control chart - this chart I use occasionally to try to understand why some tasks took forever to finish, it shows you what time your tasks spent in each state. This can be useful to highlight a bottleneck in testing or with reliance on other areas of the business.

* The new version charts - estimated end date - are useful but need improving a bit (thankfully Jira Agile is updated very often)

There are issues with it though too, as there are with any tool, and some of these funnily enough come from how configurable it is. Because you can setup Jira & Agile any way you want you can make a real dogs dinner.

Not sure if that helps at all but hopefully a little.

Regards,

Martin

[martin.mctighe]

Hi there Ivar,

Interesting question, for my team if the bug has been added as part of a story it doesn't get estimated it just needs to get fixed. If this means the story isn't finished then so be it, we can look at that again in the retro/planning session. This is part of the "Done" criteria.

If the bug is in a related area (but not directly altered during the sprint) we would just add it to the backlog (assuming the bugs weren't more important than the other work we were doing).

The estimation of bugs in general we have always struggled with, at the moment we are trying the following:-

In the grooming for a sprint we give 30 mins to determine if a bug is reproducable (or even fixable).

After that if the issue is known/understood we just estimate.

If the issue is not known/understood we create a time-boxed investigation task to continue grooming.

For really serious and unknown issues we do some brain storming and create a mini-backlog of things we could do to understand the problem and estimate those.

I'd also be interested in what other people do for bug estimation.

Regards,

Martin

[Ivar]

Thank you again for spending time answering Martin :)

(it seems I have to make this an answer, since comments cannot be larger than 2000 characters :))

Thing is, we've been using story points for estimates since beginning of 2011. We haven't been estimating the actual stories, but during sprint planning with breakdown of issues, all sub-tasks have been estimated to sp's. There has been no matching between sp's and hours.

There are a couple things that make us change our process a bit. The first is the preparations for the spring planning, prioritizing the different issues. Today, the Product Owner prioritizes the issues needed in the next sprint before the sprint planning. By the way - the development team is in Manila, the customer (PO) and I am in Norway. The sprint planning then takes place, and I adjust the commitment when we look at the estimates (story points) vs. velocity. I usually remove one or several issues with low business priority.

This "removal" of issues should not be a very big deal as every team member is aware of the fact that the higher the business value (e.g. in our "house", 1 is most important, higher numbers are less important), the less probability that it will be implemented during the sprint if a major bug is found, etc. Still, this creates quite a stir. So I need to introduce something in advance to have a better understanding of the size of the sprint during the preparations. E.g. we introduce estimates of the stories up front so we have something to measure against.

With estimates up front, estimating in story points on the subtasks seems "double up", and the story points for a sprint suddenly doubles (estimate on issue + estimates on subtasks) without this giving me, it seems, any better way of making sure if we hit our target or not. This is also why I wrote this question a couple of days back: https://answers.atlassian.com/questions/205682/is-the-story-points-burndown-really-helpful.

This leaves me in a situation where I have a burndown that isn't really helpful from my side. E.g. I need something more.

After reading a lot of the rapid boards here lately, and conferring with a senior college, it seems that very few people are estimating sub-tasks (e.g. "actual" work) in story points. They all use hours at this level. As this will actually give me a burndown that at least tell me that hours are spent as expected (doesn't really say that much about real progress, but the two combined give me a bit more overview sitting half the globe away), I have ended up with an attempt to do it this way on a "sub-project".

I am very much open for suggestions on how this can be improved :) I do not really like to move away from story points, but I feel there is really no option with the way Atlassian has moved with the rapid boards.

[Marla Landolt]

Tx Ivar. I don't have anything new to add, except that we, too, are remote across three countries Europe, and only estimate the 'mother' Stories in Story Points. We do two-week iterations always holding per teleconf a ca. 2 hr grooming & planning session before the sprint start. We (unfortunately) do not have the luxury of breaking all stories into sub-tasks before the sprint starts. But, we do try to talk it through during our grooming session and estimate as best as possible. At least we are consistent from sprint to sprint (remote team since 1Oct13).

(I'm currently fighting with Jira agile in case where I had issues that we didn't estimate until sprint already started (then it doesn't get counted!?)

[Ivar]

Thank you for answering Martin! At current I get much to few answers on "process related" questions like this - maybe Answers is the wrong forum for them?

The bugs are sort of akward for Scrum. Some might say that the initial estimate of a story should include everything that is expected in regards to the implementation, hence, 40 story points should include some effort to fix the bugs that are introduced with the new functionality (as long as QA find them).

My question is also Rapid Boards/Statistics/Velocity related. If a issue is estimated to 40 story points, all sub-tasks are estimated to 40 hours, and we end up with a 10 hour bug fix in addition before the story is complete, what happens then with the statistics? Expected 40 sp vs. 40 hours is now 40 sp's vs. 50 hours? For some sprints you will then have a velocity of X while effort is Y, in others you will have way different numbers. Will agile (Jira) "take care of this in the big picture", e.g. nothing to worry about?

In regards to how we've been dealing with the bugs before the rapid boards - things introduced during implementation is expected to be taken care of (e.g. definition of done). No change to estimates in this regards. Some minor issues can be moved to the next sprint (e.g. minor UI stuff for one browser only). Bigger issues found between sprints (e.g. production or QA doing some monkey testing) is estimated during sprint planning as any other issue and planned accordingly.