How to Deal With Bugs in tinyPM?

Marcin Niebudek

We offen get this qustion, so it may be a good idea to quickly answer it here as there are at least 3 different approaches possible.

Task in the original story

You can put a bug as a task in the original story. We use this approach when bug is found within the same iteration where the story is developed. We simply add a task and fix it in the same iteration. Bug found in the iteration must be fixed in the same iteration as the definition of done for stories contains “no known bugs”.

Separate story card

You can put a bug as as a separate story (usually as a red card). We do it when bug is found later, after the iteration where the original story was completed or if the found bug is more general and does not belong to any particular story.

Sometimes we create just a single aggregate story like “Bugfixing” and place all production bugs there as task. If the bug is serious and requires some more effort then usually has it’s own story with more task that need to be done in order to fix the bug. Bug stories are estimated as “0″ which means they have to be done but do not add up for velocity (so are treated as debt).

To estimate bugs or not is a whole different story, but we personally do not estimate them.

Sandbox

Finally you may use tinyPM’s sandbox as a place to gather bugs. There you can first check if they really are bugs or investigate them further before they will become stories. Some of them will be rejected and will never reach your backlog, some other will become stories.

Sandbox also allows connecting with JIRA bugtracker, so if you need a fully featured bugtracker and your bug tracking process is more complicated then sandbox connectors may be the way to go. This way you will keep the bugs in the external system and buffer them through sandbox in tinyPM.

Most of the time we use a mix of tasks and story cards while using sandbox as a buffer for ideas from our UserVoice forum.


1 comment

  1. szimano -

    Yep, actually we do it the same way. Moreover you can have different bug “stories”.

    What we usually do is to have few like:

    * Bugs (brilliant name, i know)
    * UI Bugs (those are for more javascript/html-gurus)
    * Bugs from last demo (compliants from the user, sometimes promoted to a story, or even worse, an iteration ;-) )

    and we find it more elegant and clear to browse


Leave a Reply