The due date represents Cantilever’s commitment to completing the work by a certain date. This can mean:
- There is a “Hard Deadline” (some real-world outcome that will be affected by us missing)
- The item is in the current sprint, even if it has no hard deadline. In this case, we as a team have committed to getting the task done by a certain date, and likely will tell clients. Therefore there is now an element of urgency around the task even when there was none before. For items outside the current sprint it is crucial that we still avoid adding deadlines when not needed, so that as we do sprint planning, we can make sure to include all tasks with hard deadlines within the sprint.
Due dates should not be used simply to prioritize work. Staff should be using the combination of Importance and Urgency (as communicated by due dates) to decide what to work on.
Due dates reflect the date that Cantilever needs/plans to ship the work, not the date that the assignee needs to get the work sent for QA/Approval.
Please expect Approvals to take at least 24 hours and QA to take up to 48 hours. Due dates on approvals should reflect this potential turnaround time gap. For example, if a task is due on Friday, creative approval may be required by Tuesday so that QA can start on Wednesday.
Project managers will be watching to make sure that things are going to approvals at the right times, and intervening if necessary, but PMs are not responsible for assigning approvals.
Exception: When client approval is needed, we should use the date of delivery to the client, then reschedule for launch. Alternatively we can create a completely separate task for launch, depending on how intense the launch is.
Example: JT is building a new page which does not require client approval to go live. The date is May 12. This means Cantilever has promised/planned for the page to go live on May 12. Therefore JT should pass for Technical approval by May 9 at the latest, and make sure to alert the intended QAer/Reviewer ahead of time so they are aware. After technical review is complete, the reviewer can pass to the QAer, or the original responsible party can do that.