1 to 8 of 8
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.
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.
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
Please help me with this.
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.
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!
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.
1 to 8 of 8
Comments are closed.
For more Intervals help documentation, please visit help.myintervals.com