It's all about the answers!

Ask a question

Closing an WI before Start No Earlier Than constraint leads to error message in Planning Problem Check (RTC 4.0.6: Traditional Planning Problems Check)

Heike Hefner (845) | asked Oct 06 '14, 11:27 a.m.

When creating a Release WI, we automatically create related Milestone WI with a constraint “Start No Earlier Than” (calculated from due date of the Release). As not all projects need all milestones, we defined a status “not applicable” (in OSLC Group “Closed”).

Our Problem: when a Milestone (having a future start date, e.g. Oct, 15th,14) is set from initial status “new” to “not applicable” (e.g. on Oct, 1st), the “Traditional Planning Problem Check” creates an error message: ”The work item has a Start No Earlier Than constraint for 15.10.14, but it is planned to start on 01.10.14.”

What other possibility do we have to “delete” unneeded work items?

One answer

permanent link
Ralph Schoon (63.3k33646) | answered Oct 06 '14, 11:41 a.m.
I would suggest to remove the constraint “Start No Earlier Than” before closing the work item. It should not have the constraint in the first place, since you close it anyway. Alternatively you can make the state not a closed state. I assume you don't want that however.

I am not sure about this, but does this happen in the work item UI or only in the plan UI. If it happens in the work item UI as well, you could try to remove the constraint checking from the plan, but I assume you want it where applicable.

Heike Hefner commented Oct 22 '14, 8:40 a.m.

Unfortunately, your proposals don't solve our problem.

Your assumption that we should not have the constraint date in the first place is correct only for 20% of our projects. That's why we decided to generate and calculate the milestones automatically (backwards from Release WI Due Date) when a new Release WI is created.

Of course, it is possible to remove the constraint and the constraint date manually, but that's rather inconvenient, so we are looking for a workaround.

To make the state not a closed state, doesn't help either. That's been our first idea, but it led to the error message described above. So we changed the state into a closed state, hoping the error message would disappear.

The main question is:
Why are "Traditional Planning Problems Checks" performed on closed Work Items? Is it a bug or what can we do to avoid that?

BTW: We use milestones only in plan UI.

Ralph Schoon commented Oct 22 '14, 8:51 a.m.

Heike, this has, for all I know, been designed that way.

If you have a constraint that you can not start something earlier than a certain time, but someone does start the item (by moving it from the initial state to an in progress or closed state), the check provides you with the warning.

I don't think there is a finer grained configuration that allows you to get certain checks and not others. I think you get all in a package. If you don't agree with the implementation,  the best option you have is an enhancement request.

Heike Hefner commented Oct 22 '14, 9:17 a.m.

There is a possibility to get less checks: "Planning Problems Checks". When using this check, the error message described above is not shown any more.
But as this other "Check package" is only described only exemplary (see our other thread:, we cannot decide, if we have in fact an advantage with this option - or if we loose other important checks.
That's just how it is...

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.