Estimated time and subtasks

Added by Bernd Worsch over 3 years ago

I would like to understand the logic of estimated time and subtasking. Hopefully someone is able to clearify or provide a pointer to the relevant documentation.

Our usecase ist as follows:
1) We use a tracker named UseCase to capture requirements.
2) We estimate time to realize the requirement and put it in the "estimated time" field of the UseCase issue.
3) When implementing to meet requirements we add issues (of tracker Feature, Job, etc.) as SubTasks to the UseCase.
4) We add estimates for the subtasks.
5) When implementation is finished we want to compare the estimates of UseCase vs the sum of SubTask estimates vs. tracked time to improve future estimates.

My understanding is that adding subtasks alters the behaviour of the "estimated time" field of the parent task. Data provided there will be lost (or no longer available) and the sum of "estimated time" fields of subtasks will be displayed.

This came as a surprise and I fail to see why this behavior would make sense. The current implementation doesn't work well with our current workflow and I wonder how other users of Redmine deal with this situation.

Replies (6)

RE: Estimated time and subtasks - Added by Bernd Worsch over 3 years ago

Ok, i dove into the subject and find i'm not alone.

So i'll provide some history:

Subtasking was #443 and got implemented as r3573. There is a somewhat lenghty discussion on the issue at #5490.

Reading through this stuff I find myself supporting the opinion that current behavior is counterintuitive and kind of breaks subtasking.

Maybe one could think about variants of how subtasks will be linked with their parent tasks influencing how information rolls up or not. But I feel roll-up is wanting too much and thus results in conflicts with too many usage scenarios. Especially if rolled-up information ends up modifing the parent task, roll-up is bad. From my point of view controlling a task from subtasks is a project-controlling-no-go and must not be done without approval of the project manager.

I advocate that:
A) Default behavior should be to keep fields on different issues intact and available at any time.
B) Roll-up of information is helpful as additional information to be displayed in parent tasks.
C) Resetting fields in parent tasks based on values in subtasks might be helpful as an action to be triggered from the parent task.
D) It would also be helpful to have reports comparing rolled-up information with the respective fields of the parent task.

A should be trivial, B should be fairly obvious to implement. I expect C to require implementation with various variants, options or local extensions to mach the workflow of the company or team using redmine. D might suggest some kind of best practices of project controlling and appeal to a more general audience if done right.

Best regards and thanks for comments!

RE: Estimated time and subtasks - Added by Pavel Potcheptsov over 3 years ago

I don't now if it's the same, but I posted it as issue here

RE: Estimated time and subtasks - Added by Stephen Curran over 2 years ago

Has anyone come up with a way to get around the "adding a sub-task removes the parent task's estimate" issue? I understand the current semantics and agree it's not totally obvious that the current behavior should be eliminated, but I would like to have the option that a parent task's estimate remains whether or not there is a sub-task on the issue. We're really struggling with the current behavior.

Our use case is fairly straight forward:

  • A task is created with an estimate and assigned to a developer.
  • The developer works on the task and discovers they need a sub-task to
    • (a) help them manage their work, or
    • (b) to assign to another developer
  • The creation of the sub-task is independent of the original estimate - it should leave it alone

With the current behavior, the estimate is lost on creation of the sub-task. I've not found any easy way to workaround that - even ugly hacks like, creating a shared parent before creating the sub-task don't really work (because the second task is INTENDED to be a sub-task of the first).

Has anyone else dealt with this use case in Redmine and come up with a satisfactory solution?

RE: Estimated time and subtasks - Added by Stephen Curran over 2 years ago

And now I see that 14 days ago, revision r14272 was made on task #16092 that appears to address the issue. Cool! Looking forward to seeing when that comes - even more to see if we can apply it early.

RE: Estimated time and subtasks - Added by Mischa The Evil over 2 years ago

To complete: r14269, r14270 for issue #5490 and r14273 for issue #17550 were recently committed too. This is a real progress compared to the strictly derived defaults currently.
OTOH, I haven't tested this in-depth enough yet to say that there're no more side-effects anymore which can be considered undesired (eg. my otherwise unrelated, old issue #6687).

Hope this helps...