It's all about the answers!

Ask a question

Plan items removed from taskboard when last child completes


Patrick Paquette (371017) | asked Dec 03 '18, 10:29 a.m.

We've noticed the following behaviour:

Taskboards shows all planning items in the iteration, and their children tasks.
Planning items in the iteration that have no children show up.
As soon as a planning item has it's last child that is done, the planning item is removed from the plan, and the only way to put it back on the board is to give it a new child which isn't done.

Is there a way to turn off this feature?  We've been using the taskboard to run our standups, and if we finish the last task in a story and there's still more to do but doesn't have a task, it is removed from the board, even though the story is not done.

RTC 6.0.5


Comments
Gabriel Enriquez commented Dec 03 '18, 6:18 p.m.
JAZZ DEVELOPER

  I'm curious what are the Options you have configured in your plan view. Particularly, what exclude options do you have on your Taskboard view?


The only way I was able to reproduce this behavior was with an "Exclude: Resolved Items" and have the actual planning item in the resolved state (e.g., Story -> Done). Although, you mentioned "... even though the story is not done".


Patrick Paquette commented Dec 03 '18, 7:53 p.m.

 Some screen shots:


Before moving last child task to done, as well as exclude options.  Only "Exclude Resolved Items" was set.  Everything else is just color.

Moving last child task to done, before save.

Last child task moved to done, planning item also removed.

I'd post the image, but I don't have enough rep. 


Gabriel Enriquez commented Dec 04 '18, 1:30 p.m.
JAZZ DEVELOPER

 Thank you for sharing your configuration, but still cannot find that behavior.


One theory is that the Planning Item's current state ("...even though the story is not done") belongs to the "Closed" State Group. Can you check that under its Work Item Types / Workflow configuration?

If that is not the case, please also share your current plan details (owner, scope, include all items, etc.). and team hierarchy.


Patrick Paquette commented Feb 27 '19, 4:04 p.m.

Ok, I figured it out.  It happens because the state of the planning item (in this case, "Implemented") is not on the presented list of columns.  If I change its state to one which shares the same name as one of the columns (like, In Progress), it appears. It just happens that our planning items shared the same state names as our execution items, except for "Implemented" - until recently, when we added the "Ready" state to help with grooming our planning items (which we don't do on execution items).  Now, none our of "Ready" planning items show up on the board until they have a child.


Sounds like a bug in the design to me...why would the planning items have to share the same state name?


Patrick Paquette commented Feb 27 '19, 4:06 p.m.

 As a work around, we'll show those columns (even though execution items could never get to those states), and collapse them.


Patrick Paquette commented Apr 25 '19, 1:08 p.m.

I was curious - is this expected behaviour?  We're in the process of renaming the states of our process to accommodate... 

showing 5 of 6 show 1 more comments

One answer



permanent link
Ralph Schoon (58.2k23642) | answered Apr 25 '19, 5:18 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I would expect that items filtered away as described above, would not show up. This would be as designed. It makes sence and is logical.

My general experience is that assumtions I would jump to, showing behavior in my favor in borderline conditions usually never happen. Provided minimal information given such as versions (not available here) I can only test what I see and assume it is the desired behavior in examples like the given one. It is almost impossible to comment on 'expected behavior' of complex tools like RTC, if you did not develop the code yourself.

Comments
Patrick Paquette commented Apr 29 '19, 11:36 a.m.
 "I would expect that items filtered away as described above, would not show up. "

That would mean you would expect all planning items to share the same states as execution items. Consider the out of the box Agile template's Sprint Plan.

1. Edit taskboard to not show resolved items
2. Put a story into the implemented state
  - Note how the story is still on the board (this is correct)
3. Make a child task of this story.
  - task appears on the board
4. Move the task to Done.
   - both *the Story* and task is removed from the plan board (*story removal = not expected/design bug)
5. Now, modify the taskboard again to include the Implemented column
  - the Story now reappears, and the Done task does not


Patrick Paquette commented Apr 29 '19, 11:43 a.m.
 "I would expect that items filtered away as described above, would not show up. "

That would mean you would expect all planning items to share the same states as execution items. Consider the out of the box Agile template's Sprint Plan.

1. Edit taskboard to not show resolved items
2. Put a story into the implemented state
  - Note how the story is still on the board (this is correct)
3. Make a child task of this story.
  - task appears on the board
4. Move the task to Done.
   - both the Story and task is removed from the plan board (*story removal = not expected/design bug)
5. Now, modify the taskboard again to include the Implemented column

- the Story now reappears, and the Done task does not 


Patrick Paquette commented Apr 29 '19, 11:43 a.m.
Note how the story is not resolved.  It is still "In Progress", but is removed from the board.  There's more to do, but you may not have made a child task yet.

So we can fix this by keeping the Implemented state on the taskbaord, but there's no need to put a planning item state on a task board, only on the Kanban.  Even if you tried, by changing the child task above to a story in the above example, it would still only shows on the left.  Another design bug.  Taskboard should not allow you to put states that only belong to planning items as a column.

"My general experience is that assumtions I would jump to, showing behavior in my favor in borderline conditions usually never happen"

I wouldn't call this border line conditions.  I would image it is quite common to end all tasks in a story that is in the implemented state, when you don't make all your tasks to complete the story up front when it's New, and you only make them as needed.

 


Patrick Paquette commented Apr 29 '19, 11:43 a.m.
"Provided minimal information given such as versions (not available here)"

RTC 6.0.5, as mentioned in the original post

"I can only test what I see and assume it is the desired behavior in examples like the given one"
"This would be as designed. It makes sence and is logical. "

So, this is not the desired behaviour, does not make "senSe", nor is it logical - particularly given the examples above.

If we assume when executing test cases that the design is the desired behaviour without asking yourself what the user would do, this is dangerous.  Ever hear the joke "Do know what happens when you ASSuME?" :)

 


Patrick Paquette commented Apr 29 '19, 11:44 a.m. | edited Apr 29 '19, 11:44 a.m.

 "It is almost impossible to comment on 'expected behavior' of complex tools like RTC, if you did not develop the code yourself."


Then we have a different definition of "Expected Behaviour" .  I interpret the above statement meaning "The expected behaviour of the software is what was coded".  As a user of this software (and a developer of others), Expected Behaviour has nothing to do with what WAS/IS built, just what the USER expects.  In our software development shop, we call that a design/UX bug.

Your answer


Register or to post your answer.