How to query for work items with ALL children resolved?
Mike Shkolnik (980●8●161●143)
| asked Sep 14 '11, 7:10 p.m.
retagged Sep 21 '12, 5:05 p.m. by Richard Knaster (238●1●7)
I am trying to query for stories/epics that need to be closed based on all their children being closed. I can query for ANY children resolved:
Status - is - Unresolved Children> Status - is - Resolved but I can't seem to query for ALL children resolved. Is there some way of doing this, or am I out of luck? |
7 answers
This is an old question, but I thought I would post a note on here. We ran into the same difficulty in our environment. I eventually came to Jazz.net and started linking all the enhancements I could find that seemed to be requesting this capability. I think I found 3 or 4. Here is one of them: https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/165456 In our situation, we came up with a workaround by developing an operation behavior (follow up action) that would count the number of blocking work items whenever a work item was saved and store that number in an attribute (which we called "Blocking Link Count"). We could then query for work items where the Blocking Link Count is zero. Before we came up with that solution, we developed a stand-alone application that used the REST API to figure this out. So it was essentially a report. Before that REST API solution, a proposed technique is to look at the plan and hide resolved work items. Work items in the plan with an expansion arrow were work items with unresolved children. If the expansion arrow was not present, then all children are closed. Just a few ideas there... |
I forgot to mention that if I add to this: Children> Status - is not - Unresolved the result is the same as without that third filter. |
|
It's been a year since I asked. Is there really no way to do this? How are people determining which stories are ready to close if you can't query for it?
|
|
I am aware this is a Scrum Master responsibility. It appears to be an entirely manual process. I can't even create a query to list all the stories that are ready for closing based on all their children being closed. The alternative is to manually check every story (by checking each story's links) every day. Will all the Scrum Masters do that? No they won't. Thus we have to wait until sprint closeout and with so much lumped into sprint closeout, the Scrum Masters aren't getting that done either. We need a real-time list of ready-to-close stories.
Currently I am telling them to "expand all" in Work Breakdown view in the Eclipse client and to look for stories where all the children are closed. Again, a manual process, subject to Human error, and subject to failure when some children were moved to a different sprint. Yes, I tell them not to do that. Also, this forces them to use Eclipse and many of them are non-coders and should be using the web interface (which has no "expand all" in version 2.x). We need a real-time list of ready-to-close stories. This is something that should appear on a Team Lead Dashboard. It appears that doesn't exist even in version 4. I have subscribed to related work items on jazz.net, but they are sitting in the backlog, unassigned. I was hoping there is a workaround out there. Something a little less manual and less error-prone. |
For this I wrote an enhancement request beginning of September:
I'm realy missing this and it should be implemented urgently! This should be a pre-configured query! |
|
Thanks for helping to get some attention to this issue. I agree with you on the importance of this. It's creating an Agile adoption problem for us. Without timely closing of Stories, the execs don't trust the system or the methodology.
I wish IBM would decide to review all query enhancement requests and do a major update to the query engine. It needs it. I am subscribed to six myself (including yours) and there are likely many more. |
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.