You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I'm getting two different requirements related to how due dates should be used. On one project the PM indicated that as we moved something to a new stage we should change the due date to reflect the date that stage is due; on another project the PM is saying you never change the due date.
The first option is what I think should be used otherwise how would you ever track when things are late or not, however, the other PM said if you change the due date you change history, that makes no sense.
You can use dates however you want, but typically, a due date would refer to when the issue as a whole is supposed to be delivered.
If you want to track specific dates for stages, you could create a separate field to track that information. Alternatively, you could track the separate stages as sub-tasks each with their own due date.
Hi @Jean Christenson welcome to the community. It has been my experience that the second PM is correct. The purpose of the Due Date is to reflect desired completion of the issue and not a completion of a transition to a new status(stage as you called it above). You could design something to reflect a status(stage) completion date or milestone date to address the first PM's requirement. My current client we have implemented a Milestone Date to address this exact thing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.