When using Agile (Scrum) in Workfront, how do you move incomplete tasks to the next sprint without skewing the first sprint's data regarding task completion percentage?

[DavePa1]

We are currently duplicating tasks so one can live in the original sprint and the other in the next sprint. This is a time-intensive process when there are dozens of incomplete tasks.

[JaneBr]

We are experiencing the same challenge and haven't yet found a way around this. We too are duplicating tasks. We decided against moving them so as not to impact the integrity of the data in the original Sprint.

[DavePa1]

Jane,

I'm glad we're not alone in this. It would seem this would be a basic expectation of Scrum, as I can't imagine any Scrum team ever selects exactly enough work to complete in the sprint.

[FrankFo]

‚We are doing the same but considering to stop that practice. Our focus has always been on the current iteration so the practice of not moving them forward has led to loosing track of the tasks that are not complete. The best practice as I understand it is to move the task forward to a new iteration. I have forgone the need to keep track of the metrics feeling that it is more important to keep focus on the tasks to be completed and to manage resources and capacity.

[DavePa1]

Frank,

I agree the current iteration should be priority; thanks for your response.

Our struggle is data integrity. Our leadership team expects to see the percent complete of planned work for each sprint, and to see whether it is at our preferred metric. If we move tasks out of old sprints, wouldn't that change completion percentage for previous sprints?

I haven't yet found a way to capture and report on the data at the moment the sprint ended. Is that possible? We use Domo as an organization, and it has the ability to access the data for a specific day or range of days. (I've stoked my own curiosity.)

Thanks!

[FrankFo]

‚Yes moving a task out of an iteration will change the percentages and statistics. I am looking at if there is a possiblity to assign the parent task to an iteration and move its subtasks in to the iteration that it is actually being worked. The parent task would not be assigned to anyone but I would hope the points and work effort would reflect the compilation of its subtasks. In summary the parent task would be the expected delivery for the iteration. if there is one subtask that is not completed in the expected delivery time then that subtask would be moved to a subsequent iteration but the Parent task would remain in the iteration where all of its subtasks were expected to be delivered.

We use SAFE Agile so we have a concept of Program Increment and so I am also looking at creating a Program Increment Iteration that would include the Request or Feature to track the delivery of the Feature or Request within the Program Increment. Basically the Program Increment would be my iteration and the Iterations which make-up the Program Increment would be Sprints. Our PIs are 10 weeks long with five sprints two weeks each.

[DavePa1]

We put our parent tasks in the iteration; they serve as Epics. We do 2-week sprints, but we often have tasks that don't complete because something wasn't ready or approved. This then necessitates moving to the next iteration. The epics do record completed story points for their subtasks.

[PatrickHa4]

I'll have to try this approach with Epics in the Iterations.

[PatrickHa4]

We created a Custom Field, which may tag a Story as "Incomplete"

1. We duplicate the incomplete Story in the Product Backlog
2. The Old Story is tagged as "Incomplete," remaining in the prior Sprint.
3. New Story is added to the next Sprint.

Agree about the extra time & work to do this.

Our management wants us to track incomplete Stories.