It's all about the answers!

Ask a question

Work items that exceed iteration plan time


Chris Faulhaber (111) | asked Feb 06 '09, 4:24 p.m.
We have some work items that exceed our iteration length of two weeks. I set the "Planned For" field of such work items to the iteration they're set to start. When the iteration is over, the work item has two weeks worth of work spent.

Naturally, the work item extends to the next iteration. I set the "Planned For" field to the new iteration and much of my information becomes inaccurate. The prior plan no longer shows any time spent on that work item, and the new plan shows two weeks of work have been done already.

This issue is not limited to work items that take longer than two weeks to complete. Sometimes the forces of chaos conspire to delay the second half of a two-day task until another iteration. It's a fairly common situation for our business.

What can be done about this situation?

6 answers



permanent link
Anthony Kesterton (7.5k9180136) | answered Feb 07 '09, 4:48 a.m.
JAZZ DEVELOPER
We have some work items that exceed our iteration length of two weeks. I set the "Planned For" field of such work items to the iteration they're set to start. When the iteration is over, the work item has two weeks worth of work spent.

Naturally, the work item extends to the next iteration. I set the "Planned For" field to the new iteration and much of my information becomes inaccurate. The prior plan no longer shows any time spent on that work item, and the new plan shows two weeks of work have been done already.

This issue is not limited to work items that take longer than two weeks to complete. Sometimes the forces of chaos conspire to delay the second half of a two-day task until another iteration. It's a fairly common situation for our business.

What can be done about this situation?


Hi

Would it be possible to split the work item into different parts. I imagine you want to recognise that you had done something in the first iteration, but have more work to do. Also, something I have not investigated, what about spawning child work items, then assigning the children to the different iterations. Keep the parent in the first iteration.

anthony

permanent link
Chris Faulhaber (111) | answered Feb 07 '09, 1:42 p.m.
Thanks for your reply. I've thought about splitting the work items into different parts, but that's suboptimal. Especially for low-priority tasks that are consistently delayed, you may end up with very useful links, attachments, changeset associations, etc., spread out over many different work items.

permanent link
Johannes Rieken (1.2k1) | answered Feb 09 '09, 3:18 a.m.
cfaulhaber wrote:
We have some work items that exceed our iteration length of two weeks.
I set the "Planned For" field of such work items to the
iteration they're set to start. When the iteration is over, the work
item has two weeks worth of work spent.

Naturally, the work item extends to the next iteration. I set the
"Planned For" field to the new iteration and much of my
information becomes inaccurate. The prior plan no longer shows any
time spent on that work item, and the new plan shows two weeks of
work have been done already.

This issue is not limited to work items that take longer than two
weeks to complete. Sometimes the forces of chaos conspire to delay
the second half of a two-day task until another iteration. It's a
fairly common situation for our business.

What can be done about this situation?


I agree with Anthony and recommend to split the work item into two. You
don't have to do that in advance but can do it when you see the work
item slips. All you achieved in iteration A is associated with task A
and what's going to come in iteration B goes into the new work item.

However, most agile methods want you to work with very short task, e.g
the longest scrum-task shouldn't be more than a working day. This allows
you to see progress quickly and to have something you can put the
'done'-check mark on.


--
Cheers, Johannes
Agile Planning Team

permanent link
Kieron Brear (1461169) | answered Feb 09 '09, 6:26 a.m.
In line with the other advice, I'd strongly recommend splitting the task into smaller elements. If there are links and attachments shared between the tasks, then consider having a parent task, or user story if using the scrum process, and having the links etc in that parent work item. In this way, users can quickly get from the task they are working on, which is sized as being smaller than an iteration, to the related information in the parent task.

Hope that helps.

Kieron

permanent link
Chris Faulhaber (111) | answered Feb 09 '09, 1:43 p.m.
Thanks for all your responses.

Again, this situation is not limited to long work items, and can occur quite frequently in chaotic environments with work item that are mere hours in length. Though not ideal, here is the work around I and my team will be implementing:

All work items will be scheduled as normal. When a work item is completed during the iteration time, it can be resolved without issue. When the work item in its entirety needs to be rescheduled, this is a simple matter of changing the plan assignment.

When a work item is partially completed, we'll be creating two child work items from it. One for the work that is completed, and one for the work remaining. All associations will continue to be made to the parent work item, and that parent will be unlinked from the iteration plan.

This seems to be the simplest way to work our process and company culture into RTC. I strongly encourage the RTC design team to create a better way of handling this. Not every organization and plan is as stable as this system is designed for, though this work around is not too onerous.

permanent link
Anthony Kesterton (7.5k9180136) | answered Feb 10 '09, 4:06 p.m.
JAZZ DEVELOPER
Thanks for all your responses.

Again, this situation is not limited to long work items, and can occur quite frequently in chaotic environments with work item that are mere hours in length. Though not ideal, here is the work around I and my team will be implementing:

All work items will be scheduled as normal. When a work item is completed during the iteration time, it can be resolved without issue. When the work item in its entirety needs to be rescheduled, this is a simple matter of changing the plan assignment.

When a work item is partially completed, we'll be creating two child work items from it. One for the work that is completed, and one for the work remaining. All associations will continue to be made to the parent work item, and that parent will be unlinked from the iteration plan.

This seems to be the simplest way to work our process and company culture into RTC. I strongly encourage the RTC design team to create a better way of handling this. Not every organization and plan is as stable as this system is designed for, though this work around is not too onerous.


Hi Chris

Please log an enhancement request via the development tab, here on jazz.net. Be sure to describe how you want this to behave.

regards

anthony

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.