2

We’re a team of a few programmers working on different projects, enhancing current features adding new features and of course fixing bugs as they come to our attention. Problem is that we need a way to efficiently divide the time available between the various tasks. we can’t work a few weeks on bug fixes and let all new features waiting, and the same is true for bugs it can’t wait for too long before getting fixed, that’s why we need to find a tool to divide the time.

Our plan is to add an estimate for each task and categorize it accordingly, this part is available in FogBugz and other similar task management tools I tried.

The other part I can’t find in the tools available is how to assign developers time to the task, and get a report on how much time is left for each category. For instance I want to divide the available time as; 25% Bug Fixes 50% New Features 25% Enhance current features

So the tool should calculate all tickets estimates, and tell me how much time I have available.

We’re open to hear other suggestions on how to manage time available against different various task types, if that’s not the standard way of doing it.

closed as off-topic by Ixrec, durron597, GlenH7, user22815, user40980 Jun 18 '15 at 1:57

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Ixrec, durron597, GlenH7, Community, Community
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    On what time scale are you trying to plan the work? A day, a week, a month, a year? – Bart van Ingen Schenau Jun 15 '15 at 16:04
  • I think will do it day by day - every day would be divided by few task types. – Ezi Jun 15 '15 at 16:06
2

You will find that it is nearly impossible to plan the work down to the granularity that you are proposing.

If you want to have the flexibility to respond quickly to changing requests from the business, while still giving the developers the stability that they can finish what they are working on before being asked to switch to a different task, then I would advice to take a look at Agile methods and Scrum in particular.

In Scrum, the team works in short iterations (between 1 and 4 weeks in length).
You would put all your bugs, new features and feature improvements in one big list and order that list in the order that gives the most value to the business. Then at the start of an iteration, the team takes as much work from the top of the list as they can handle in one iteration.
During an iteration, you can't change what the team is working on, so if an important bug comes in you can put it on top of the list and it will stay there at most for the duration of one iteration (half an iteration on average).

  • Thanks for your suggestion, but we can't afford a customer to wait with a blocking issue for more then a day or a two. – Ezi Jun 15 '15 at 18:18
  • 1
    @Ezi In which case ANY schedule you create is meaningless. Instead just do the part that Bart suggested that you can do. Put everything in one big list in priority order and as developers need a task to work on they take the top one from the queue. – Dunk Jun 15 '15 at 20:36
  • Why is it meaningless? I could allocate every day 1-2 hours for bug fixes. – Ezi Jun 15 '15 at 20:58
  • @Ezi: Fixing a bug takes 4 to 8 hours of concentrated work for a relatively easy bug. With 1 hour a day for bug-fixing, someone will be working on that small bug for 1 to 2 weeks. And that without taking into account that switching tasks adds another inefficiency overhead. – Bart van Ingen Schenau Jun 16 '15 at 5:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.