-
Suggestion
-
Resolution: Won't Do
-
None
Customers (or a representative) raise User Stories in a Customer Project. The implementation for these User Stories are then implemented against the necessary component or components that make up the Customers Product by way of a task that addresses the User Story. Each of these components has it's own project in our Jira instance.
Currently it is hard to see the tasks that need to be done (Sprint Backlog). A user has to open up the User Story, or use a custom filter.
We would like to see tasks linked by "addresses" appear under the User Story on the Rapid Board, much like tasks do.
- is related to
-
- Closed
[JSWSERVER-9664] As a Scrum Dev Team Member I want to see all tasks that are linked to a User Story by relationship 'addresses' on the Rapid Board so that I can view and progress the tasks needed to be completed across various projects in order to satisfy the User Story.
Many thanks for reporting this issue. We see it as a valid feature request however we cannot provide any guidance at this time as to when, or if, we'll be implementing it.
Regards,
GreenHopper Team
As a colleague of Nick's, co-admin of the Atlassian products used by our teams, and more importantly a Dev Team Member, I thought it worth clarifying a few points from this story.
- We have a product suite with many products. Each have their own JIRA project.
- We control our shared components in the same way. Each major library is independently versioned in its own JIRA project.
- We have many customers. Each have a different subset of our product suite (at different versions – they upgrade at their convenience).
- Each customer has their own JIRA project where Bugs and Stories raised by them are tracked.
- We have a single Rapid Board for the dev team with Sprints that may contain issues from multiple customers.
- User stories and Bugs etc are raised in the customer projects which form our primary "requirements" and are planned into sprints with Greenhopper.
- Tasks are raised against the appropriate versions of the internal (non-customer-facing) projects in order to do the work necessary to meet a Story or fix a Bug.
- These Tasks are linked from the internal component/application/library project issue to the customer Story or Bug via an "addressess / addressed by" link type that we have created.
We really like the way that sub-tasks of User Stories are visualized and managed in Greenhopper, and we wish we would use that sort of interface to manage our work. But having a sub-task on a User Story is insufficient for us; there is no direct link from the Story to the JIRA project for the component or library that is being affected.
What we'd like is for Greenhopper to allow us to specify one or more link types for a Board such that the linked tasks can be visualized on the Rapid Board as if they were sub-tasks of the related Story or Bug.
We are not asking for all the extra behavior associated with sub-tasks such as "time tracking roll-up" or "close parent issue when all sub-tasks done" (although these would obviously be nice to have!).
We primarily just want to visualize the related issues as if they were sub-tasks and be able to drag them between columns in the same way as you can with sub-tasks.
We accept that, with this scheme, a specific "related issue" may appear more than once on a board (as a "virtual sub-task" of more than one Story). In practice this does actually happen (for example if some core refactoring is being done). We are happy that a manual refresh might be required after a drag-n-drop of such an issue (though obviously we'd prefer Greenhopper to do this automatically).
This feature would improve our efficiency and visibility of work in our team (and I'm assuming other teams) significantly.
Adam Butcher
added a comment - - edited As a colleague of Nick's, co-admin of the Atlassian products used by our teams, and more importantly a Dev Team Member, I thought it worth clarifying a few points from this story.
We have a product suite with many products. Each have their own JIRA project.
We control our shared components in the same way. Each major library is independently versioned in its own JIRA project.
We have many customers. Each have a different subset of our product suite (at different versions – they upgrade at their convenience).
Each customer has their own JIRA project where Bugs and Stories raised by them are tracked.
We have a single Rapid Board for the dev team with Sprints that may contain issues from multiple customers.
User stories and Bugs etc are raised in the customer projects which form our primary "requirements" and are planned into sprints with Greenhopper.
Tasks are raised against the appropriate versions of the internal (non-customer-facing) projects in order to do the work necessary to meet a Story or fix a Bug.
These Tasks are linked from the internal component/application/library project issue to the customer Story or Bug via an "addressess / addressed by" link type that we have created.
We really like the way that sub-tasks of User Stories are visualized and managed in Greenhopper, and we wish we would use that sort of interface to manage our work. But having a sub-task on a User Story is insufficient for us; there is no direct link from the Story to the JIRA project for the component or library that is being affected.
What we'd like is for Greenhopper to allow us to specify one or more link types for a Board such that the linked tasks can be visualized on the Rapid Board as if they were sub-tasks of the related Story or Bug.
We are not asking for all the extra behavior associated with sub-tasks such as "time tracking roll-up" or "close parent issue when all sub-tasks done" (although these would obviously be nice to have!).
We primarily just want to visualize the related issues as if they were sub-tasks and be able to drag them between columns in the same way as you can with sub-tasks.
We accept that, with this scheme, a specific "related issue" may appear more than once on a board (as a "virtual sub-task" of more than one Story). In practice this does actually happen (for example if some core refactoring is being done). We are happy that a manual refresh might be required after a drag-n-drop of such an issue (though obviously we'd prefer Greenhopper to do this automatically).
This feature would improve our efficiency and visibility of work in our team (and I'm assuming other teams) significantly. 
Hi,
Thank you for raising this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Sometimes potentially valuable tickets do get closed where the Summary or Description has not caught the attention of the community. If you feel that this suggestion is valuable, consider describing in more detail or outlining how this request will help you achieve your goals. We may then be able to provide better guidance.
For more context, check out our Community blog on our renewed approach to highly voted Server suggestions for Jira and Confluence.
Thanks again.
Regards,
Jira Product Management