Work Item Dependency - Some Work Item need to be worked on inorder
Work Item Dependency - Some Work Item need to be worked on inorder
We have a Story and Children Tasks(created by a Template) which list the Testing activities which in some cases have to be done in a certain order and before other Tasks.
Preferable not to use any Start and End Dates but actual WI ids or ordering
We have a Story and Children Tasks(created by a Template) which list the Testing activities which in some cases have to be done in a certain order and before other Tasks.
Preferable not to use any Start and End Dates but actual WI ids or ordering
One answer
There is really nothing that enforces that as far as I know in the agile templates, you rank the work items and the users that pick it up bring them into an order that they can, but don't have to keep.
There are dependencies/work item links, that you could set up, or you could use other data to model order and dependencies in RTC. However, there is no built in mechanism that enforces this, as far as I know.
It would be possible to implement pre-conditions/adviusors that prevent the state change of a work item based on such dependencies. Start reading here to learn more: https://rsjazz.wordpress.com/2015/09/30/learning-to-fly-getting-started-with-the-rtc-java-apis/
Such a pre condition could for instance prevent the work item state to be changed to the in-progress state group, if there is a work item that it depends on and that is not closed. Alternatively it could prevent it to be closed, if the one it depends on is not closed.
From my perspective this is eyewash, however, since no one can prevent the user to start working without changing the state. Tools can only do so much and for example hint that something needs to be done before. You finally rely on reliable users.
There are process tools like Stages that have more process control capabilities, but even then, you can not prevent what you don't detect. So the question is, can you detect it. If the next task requires some artifact to actually be started or rather finished, it might be detectable, but again, you can't prevent a user to think about the next task.
As a last thought, there is a built in pre condition/advisor that prevents closing a parent work item if the children are not closed, so you could get some control, but it does not care for the order of the work done on child work items on one level. You could use this and add children to an item that need to be completed first though.
So if you need a task done before another, add it as a child to that task. Since parent child is 1:n, there are limits in what you can model, I guess.
There are dependencies/work item links, that you could set up, or you could use other data to model order and dependencies in RTC. However, there is no built in mechanism that enforces this, as far as I know.
It would be possible to implement pre-conditions/adviusors that prevent the state change of a work item based on such dependencies. Start reading here to learn more: https://rsjazz.wordpress.com/2015/09/30/learning-to-fly-getting-started-with-the-rtc-java-apis/
Such a pre condition could for instance prevent the work item state to be changed to the in-progress state group, if there is a work item that it depends on and that is not closed. Alternatively it could prevent it to be closed, if the one it depends on is not closed.
From my perspective this is eyewash, however, since no one can prevent the user to start working without changing the state. Tools can only do so much and for example hint that something needs to be done before. You finally rely on reliable users.
There are process tools like Stages that have more process control capabilities, but even then, you can not prevent what you don't detect. So the question is, can you detect it. If the next task requires some artifact to actually be started or rather finished, it might be detectable, but again, you can't prevent a user to think about the next task.
As a last thought, there is a built in pre condition/advisor that prevents closing a parent work item if the children are not closed, so you could get some control, but it does not care for the order of the work done on child work items on one level. You could use this and add children to an item that need to be completed first though.
So if you need a task done before another, add it as a child to that task. Since parent child is 1:n, there are limits in what you can model, I guess.