Adjusting planned dates in an iteration

This is much needed, please update this, WF! Not every issue/task should need to be due the end date of an iteration, we need flexibility to change due dates to fall within the iteration timeframe. We are having to write in the due date we want in the task name, which is not only confusing for the assignee seeing 2 different dates but also for the PM not being able to change planned due dates easily.

This is a huge painpoint for our team in Workfront, as our team entirely uses the agile sprint view. We've had to implement a lot of workarounds in the meantime and Kanban doesn't work for us for other reasons (aren't able to divide work into sprints or show hierarchy between parent and children tasks in our sprint board). This would make it much easier to collaborate with other teams on shared projects, would reduce stakeholder confusion on deliverable date sand would make it easier to recommend Workfront to new teams who haven't been onboarded as well.

This is critical for our team to realize the efficiency gains to be had. We collaborate with multiple teams, some work in sprints, some kanban, and some waterfall, and often times these tasks roll into a larger project template with strict deadlines due to the nature of the business. We need to control end dates as the sprint team task is a predecessor for others and a task being completed at the end of a sprint unnecessarily bloats the timeline. This restriction also prevents us from adding more teams to the system who continue to use Jira or other systems and are not connected to our flows.

We have same requirement, it will ease in many ways.

I have been a SM, PO, and a PM at this point in my career. while I did my time in the SM/PO world, it was a common complaint that my PMs were unable to adjust dates within the iteration, in addition to this, the dates of the iteration also adjust the dates within the project. I would like to see this! Upvoted!

I'm in the same boat. In fact, I'd say the date issue is one of the biggest factors in moving to Agile Marketing Management. Tasks have due dates that are dictated by things entirely outside of the iteration time boxing, like editorial calendars, print dates, and intersections with product launches and other promotions. Forcing all the tasks/issues to have the same end date as the iteration screws all of this up.

This is applicable for some of the work that comes in to one of our Agile teams - most work is fine to be assigned the S/F dates of the sprint, but there are a few items that have a specific due date at some point mid-sprint. We end up adding the actual due date in the title of the task, which is a fine workaround, but it can cause confusion at times.

Not only does it set the planned completion date, but it does so without any consideration to predecessors. Even on an agile team you may be a dependency within an iteration where one user story must complete before starting on the next. Being able to reset the planned dates will allow the team to account for that.

If the waterfall project views are still important, then WF should be configurable to override the planned completion date or not. Choosing one approach obviously doesn't work for everyone.

I agree with the sentiment and have upvoted this.

But I think the problem is with mixing agile and traditional methodologies, not with the WF implementation. How WF is currently working is technically correct from a process point of view.