Feature #1953


Due date calculation based on developer's estimations

Added by Mauricio Miranda over 15 years ago. Updated almost 5 years ago.

Issues planning
Target version:
Start date:
Due date:
% Done:


Estimated time:


We have been using FogBugz ( for some time and I think it's a really good (commercial) solution. A few days ago a friend told me about Redmine, I was trying it and I have to say I am in love with it (geek? Nooo...)

We just need one specific functionality we have in FogBugz and it's very important for us. I'll try to explain it:

  • Each version must have a new field: 'Start Date'.
  • Each user (developer) configures on his own account the days and the hours he spends working on the project. We will need some new tables/fields here.
  • When an issue is assigned to the user, he estimates the time in hours. We can use the existing 'Estimated time' field.
  • Based on this data (start date, user time and user estimations) we can calculate (on the fly) the version 'Due Date'.
  • We can calculate the due date for each user and for the whole version. And may be for the whole project too (Is it too much?).
  • If the issue is reassigned, if the user changes the estimation or if somebody changes the start date, then the due date is updated automatically.

This is probably a simple feature but we think it's very useful for the managers or the marketing people involved in the project.

There is another related functionality FogBugz implements and it's really great. It saves logs with the spent time on each issue by the user and it uses these logs to create some kind of 'profile' of the user with his estimations accuracy. This allows us to create a probability sheet with the due date, eg: the due date will be at '10/20/08' with 25% chance and '10/28/08' with 50%, and '11/15/08' with 75%, and '12/31/08' with 99% (100% doesn't exist ever). To create this, we need to know when the user starts or stops to work on each issue. May be we can use the 'start/stop' button asked by Anna Labinskaya or any other way (

This is not so simple but we can build it when we finish the first feature.

Please, let me know your questions or concerns. I can add some mockups and/or screenshots if I was not enough clear.

Thank you!


issue_1953.diff (7.13 KB) issue_1953.diff Patch To Update Due Date When Estimated Hours Is Set David Davis, 2009-12-28 21:51

Related issues

Related to Redmine - Feature #2687: different estimated time units hours<>days per tracker typeNew2009-02-06

Actions #1

Updated by Anonymous over 15 years ago

I'm all in favour of this too.

This is the one reason that I nearly chose FogBugz over Redmine (we may still switch - nothing is ever set in concrete!), and it's a really important one at that.

Actions #2

Updated by Jeff Dombach over 15 years ago

I vote for this as well.

I am using Redmine until I can cost-justify Fogbugz. I also prefer the method Fogbugz uses of the developer inputting the number of hours remaining instead of percent completion.

Actions #3

Updated by Mauricio Miranda about 15 years ago

  • Assignee set to Thomas Lecavelier

I created this feature request 2 month ago and I have no response from your side. We really think it's a good and very useful feature and we can contribute to the project developing if you agree.

Btw... Thomas, I assigned it to you because you answered my question on the forum (

Actions #4

Updated by Mauricio Miranda almost 15 years ago

  • Assignee changed from Thomas Lecavelier to Jean-Philippe Lang
Actions #5

Updated by Michael Diederich over 14 years ago

+1 - I also request theses features!

Actions #6

Updated by Mauricio Miranda over 14 years ago

I think there is a lot of people who would like this feature but nobody from redmine answered or commented the issue. May be we can build it as a plugin but I think the best way is to add it to the main structure. Let me know what you think.

Actions #7

Updated by Eric Davis over 14 years ago

  • Assignee deleted (Jean-Philippe Lang)

Mauricio Miranda wrote:

May be we can build it as a plugin but I think the best way is to add it to the main structure. Let me know what you think.

Building a plugin would be best. Once the plugin is ready, we can see about adding it to the core.

Actions #8

Updated by David Davis about 14 years ago

+1 for this feature from me as well. Is anyone currently working on this? Just wondering if this is actually under development in the mainline or as a plugin, or if it's stalled. I might be willing to contribute some time to trying to implement this if it's not currently going anywhere.

Actions #9

Updated by Mischa The Evil about 14 years ago

Maybe the Schedules plugin fills your request partially?

Actions #10

Updated by David Davis about 14 years ago

I banged out an attempt at this feature and submitted a pull request from edavis10 on github. We'll see if it makes it in, as it's my first attempt at contributing to Redmine. I'll post an update here if the functionality does make it in, and if it doesn't maybe I can figure out how to make a plugin that would add the functionality that way.

Actions #11

Updated by Eric Davis about 14 years ago

David Davis:

Could you post a link and/or patch here? I'm the only one that gets pull requests and I don't want to roadblock this issue if I'm busy.

Actions #12

Updated by David Davis about 14 years ago

Posting patch; this is based on redmine 09e47a3b6325c109c63a70dc47a9a8e32e762b44 as head.

Actions #13

Updated by Yuri Tkachenko almost 14 years ago

Can this issue be implemented into one of next releases?
I think it's very important, let it be optional, but it'll be a big plus to Redmine.

Sorry for my English :)

Actions #14

Updated by Najam Alvi over 13 years ago

Is this implemented or not. We are looking for it desperately .

Actions #15

Updated by Etienne Massip almost 13 years ago

  • Category set to Issues planning
  • Target version set to Unplanned backlogs
Actions #17

Updated by Terence Mill almost 13 years ago


Especially we like the estimation accourancy profile thing. This will create a retroperspective on every version cycle and leaning curve for better estimations and make them more expert. In fact it should be possible to have them anonymous per feature/version or per personalized.
Great idea!

Actions #18

Updated by Marcel Ritter about 12 years ago


I also totally require this feature as well. But I would like an additional or different feature.

It would work the following:
For a Milestone (or Version in Redmine) I define Issues. I would specify the time estimate, an assignee and a unique priority number (e.g. added as a custom field).
Now, Redmine should be able to compute the start and end dates for each issue in the version, based on priorities (higher priority number first), issue depencies (relations, predecessors first) and assignees (issues can be done in parallel by different people).

I would also be willing contribute, since I'm a developer myself. (Unfortunatly I'm not into Ruby, but c++. Maybe I could help to write the algorithm, when having some of your expert-ruby-assistance. :) )

I really require this! :) Or was it already added meanwhiles? Answers and comments are highle appreciated!!

Actions #19

Updated by Rick Hunnicutt almost 12 years ago


This sounds amazing! Would love to see it implemented.

Actions #20

Updated by Andy Ivanov over 11 years ago


Actions #21

Updated by Bernd Worsch over 10 years ago


Actions #22

Updated by Santiago Burgues over 10 years ago

Definitely need this!! Currently we have to do our planning on MS Project, then add all the same tasks to Redmine using the dates info MS Project gave us.

Each time we need to move the start date of a task (and believe me, that happens a LOT, mainly when we work on our in-house projects on our free times) we have to manually change all the dates. Think of that when a project has 100+ tasks, it takes at least 2hs to update all the tasks...

Actions #23

Updated by David Tremblay about 10 years ago

at least to be able to choose between due date or duration

Actions #24

Updated by Brad Smith almost 10 years ago

All my +1s to this. Frankly, this is huge, and I'm a bit irritated that I've spent the last couple of days trying to get Redmine to do this. Using duration as an alternative to explicit due dates is a basic feature of every project management tool I've ever used. It didn't even occur to me that you simply wouldn't be able to do it in Redmine. Lacking this basically prevents it from being usable by me, so I really hope this gets some attention soon. :(

Actions #25

Updated by Brian Lindahl almost 10 years ago

Here's my solution. It assumes 8 hour workdays and that Saturdays and Sundays are skipped as non-work days. It should be easy to adapt if your work schedule deviates from this.

Add the 'Custom Workflow' plug-in:

The Custom Workflow plug-in is extremely powerful and you can use it in many ways to customize Redmine to a pretty high level. It basically executes custom code before and after saving an issue. Create a new custom workflow as follows.

When Start Date or Estimated Hours changes, updates the issue Due Date. Saturdays and Sundays are skipped and and its assumed that there are 8 Estimated Hours per work day.

Code block (left side):

if leaf? && self.start_date && self.estimated_hours
  if start_date_changed? || estimated_hours_changed?
    self.due_date = self.start_date + (self.estimated_hours+7)/8
    non_work_days = 0
    (self.start_date..self.due_date).each do |date|
      if date.wday == 0 || date.wday == 6
        non_work_days += 1
    self.due_date += non_work_days + 2*(non_work_days/7)
Actions #26

Updated by Txinto Vaz almost 7 years ago

Brian Lindahl wrote:

Here's my solution. It assumes 8 hour workdays and that Saturdays and Sundays are skipped as non-work days. It should be easy to adapt if your work schedule deviates from this.

Add the 'Custom Workflow' plug-in:


Actions #27

Updated by holly chen over 6 years ago

Brian Lindahl wrote:


Thanks for Brian.
It's a big help.
But in some situations the due day will fall into weekends by your code.

I made a revision to this.
And in my redmine, the due date is the last day for the job, not the last+1
(Didn't use ruby before. If something is wrong, plz correct me.)

if leaf? && self.start_date && self.estimated_hours
  if start_date_changed? || estimated_hours_changed?
    work_days =  ((self.estimated_hours + 7.9)/8).to_i

    if work_days <= 1
        self.due_date = self.start_date
    else # >= 2
        work_days -= 1 # check from the next day.

        cur_date = self.start_date + 1  # move to next day        
        while work_days > 0 do 
            if cur_date.wday == 0 || cur_date.wday == 6 # if next day is weekend
                cur_date += 1
                work_days -= 1
                self.due_date = cur_date
                if work_days > 0
                    cur_date += 1  # move to next day

Actions #28

Updated by snow windwaves almost 5 years ago

There is also a plugin that will assign the due date based on versions and durations:


Also available in: Atom PDF