Not signed in (Sign In)
The Intervals Forum is read-only
Please head to help.myintervals.com for help articles and guides. If you have any questions, please contact our support team.

Ways to use Intervals

Bug Tracking

Bottom of Page

1 to 8 of 8

  1.  
  1.  

    When Intervals was first developed as an internal tool it had "type of Task" as an attribute. For example, "bug", "feature", "improvement", etc. We found that the additional attribute for a task wasn't really necessary. Intervals assumes "a task is a task" and works well with Bug Tracking. We use Intervals to handle bugs for our service projects at Pelago. In fact, we use Intervals to manage Intervals bugs...are we allowed to admit that?

    Depending on your work flow you can add a module for bugs, a project for bugs, or just treat bugs like a normal task. That is what we do. We typically attach a screenshot to the task with the steps used to create the bug and the expected outcome.

    In regards to who can submit a bug, we encourage all of our team to submit bugs. The Work Request Queue can be used to submit a potential bug and then the Project Manager can review it, prioritize it, and decide whether or not to assign it.

  2.  

    I think this is a great idea and exactly what we are looking to do with our use of intervals. We are also a software development company and the biggest issue for us is tracking time and assigning it to a task. We have found that it really doesn't matter if the task is a bug, feature request, enhancement, etc, it's just work that needs to get done.

    Once the milestones feature gets implemented that will be a huge step in helping to mange software projects.

  3.  

    I've a different stand on it. The 'type of task' really helps as

    1) After the 'bugs' are resolved, it should be verified by the reporter(qc team).
    2) 'Bugs' always occurs on a particular version of product. So version number is assigned to it. Not the case with 'task'

    I feel modules cannot used to specify 'type of task', as each module can have bugs, tasks, etc. This classification helps in easy management and better understanding.

    The way I need to organize the project is
    Project - 1
    ----Module-1
    -------Task-1
    -------Task-2
    -------Bug-1
    -------Bug-2
    ----Module-2
    -------Task-1
    -------Task-2
    -------Bug-1
    -------Bug-2
    ----Module-3

    Please help me with this.

  4.  

    I wish to have statistics based on the amount of work we do due to quality issues vs. the amount we expend on new features.

    How can I do this if all tasks are treated the same?

    Module isn't an option for us, because we already use this to drive billing.

    Project is also not an option, as we need all project-related tasks grouped by project.

  5.  
    Jblauer, this is the type of scenario that the modules were designed to handle. I understand they are being used for billing, so it may be necessary to repurpose another field. Task status, follower, or milestone could all conceivably be used to group tasks. Its definitely a workaround but its the only option I can think of to handle this type of task management need.
  6.  
    Another option is to update the title with more information. For example, [Bug] unable to update a task via right click. With modules you can use modules in a variety of ways to handle bugs. We have a backlog-bugs module to house all of the bugs that we want to deal with but they are low priority and are not in a current sprint. We review these bugs periodically and re-prioritize them. We have modules for each major area of the interface (Tasks, Home, Projects, Milestones, Time, etc.). When we pull these bugs out of the backlog-bugs module we change the module to the appropriate place within the interface. This allows us to create a sprint that is Task centric or Time centric. Also, it allows our developers to pick tasks that are similar in nature so that they don't get bounced around.
    • jsal
    • Jun 4th 2013 edited @ 06/04/2013 6:55 am
     

    I'm a previous user of Intervals and back with a new trial instance. I'm preparing an instance to demonstrate to the Engineer team (currently using a bug tracker with less features).
    I'm also very interested in learning about INTERVALS
    1. Account/client management,
    2. Project Management and most importantly
    3. Bug Tracking capabilities/features. (Bug, Enhancement, estimate request)
    The biggest challenge is reporting on all team/client activities under one platform and pulling a report identifying efforts.

    Michael can you give us a few more examples from how you are using Intervals as a bug tracker? Report graphic/view or similar would be a nice reference.
    Many Thanks for the discussion thread!

    • Michael
    • Jun 7th 2013 edited @ 06/07/2013 2:43 pm
     

    We use Intervals for the development and management of Intervals and have other SaaS companies using Intervals to manage their cloud-based development efforts as well. Software companies are our third biggest demographic. I will do my best to introduce how we use Intervals to manage this process.

    For bug submissions and features requests we use the Hopper to email requests directly to our Intervals Development project. Since we have multiple people on our team doing support we use the queue to hold the requests until they can get prioritized/processed. We typically process the request queue daily and sometimes multiple times per day. These requests get ruled out, backlogged or added to a sprint depending on where we are at with our release process. If you are using Intervals with client specific projects your client can email in requests or members of your team depending on your workflow.

    If you are familiar with Agile development we use milestones for sprints. Our sprints/milestones are often comprised of features, enhancements and bugs. As mentioned previously in this thread, we do not uniquely identify bugs as bugs so we don't track the total number of bugs being fixed per sprint/milestone. For obscure bugs, we have a backlog - bugs module that we revisit periodically when doing sprint planning to see if there is anything we should spend effort on. We do have a total count of tasks for that module as well as another module of backlog - being considered. We try to curate and keep those counts manageable. On occasion we do a sprint that is completely geared towards bug fixes.

    If you need reporting specifically on bugs, modules can be used to group all of the bugs together to keep track of hours and the number of tasks being created and closed. We don't do this ourselves but Intervals can definitely be used in this fashion. For reporting, there are a lot of different ways to view this data. You can view effort by task or the financial value of each task and each time entry with the Project Activity report. If you are billing hourly for your efforts the Project Activity report is probably the most powerful report to show "this is what we worked on and how long it took". More information about the Project Activity report is contained in this blog post.

    Hopefully this helps some? If you have any specific questions we can address please feel free to contact our support team directly by clicking on the "general question" link from within your account and we can follow-up and learn more about your situation and how Intervals might help.

Comments are closed.
For more Intervals help documentation, please visit help.myintervals.com