Plan items removed from taskboard when last child completes
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
showing 5 of 6
show 1 more comments
|
One answer
Ralph Schoon (63.1k●3●36●46)
| 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
"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
"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
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.
"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?" :)
"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
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.
Comments
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?
Some screen shots:
I'd post the image, but I don't have enough rep.
Thank you for sharing your configuration, but still cannot find that behavior.
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.
As a work around, we'll show those columns (even though execution items could never get to those states), and collapse them.
I was curious - is this expected behaviour? We're in the process of renaming the states of our process to accommodate...