Here is my situation. Our Release Mgmt group is responsible for final testing and all training as well as end user documentation. We create a ton of issues and a sub set of those issues when completed will need some form of end user documentation developed. Since the Release Mgmt team is somewhat disconnected from the development team there is a struggle to effectively communicate what we have built that requires some documentation. My thought was that on any issue that needs to have some end user documentation assembled we could just create a sub-task called documentation and then assign that task to that specific team lead. Then all of those documentation tasks could be seen in a specific filter and on a their own board so they can work those tasks through their own series of sprints. There are a couple of problems with this that I can see and don't yet know how to solve. If the documentation task is started and then completed in a separate sprint by a separate team will that negatively impact my dev team velocity? Can I automatically assign the documentation task to a specific team lead? Instead of using a task or sub-task should I create a related issue and have a custom issue type called Documentation? Any feedback, guidance or best practices will be greatly appreciated.
Actually, an issue and all its sub-tasks need to be completed in the same sprint. I believe the other approach is more interesting, creating a related issue using a custom issue type 'Documentation'. As for assigning it automatically to a specific team, it can be done, if you use a separate workflow for that issue type and use a post function such as 'Assign to Role Member' to set the assignee of the issue.
I hope this helps.
I tend to agree with this approach. If we create a separate Project for the Release Mgmt team and create a new issue type called Documentation and set the team lead for that Project to the person responsible for Release Mgmt then all issues of the type Documentation created within that project linked will be assigned to that team lead. Then all we would have to do is to create the new issue and link it to each of the new features, improvements or major bugs. Since it is a linked issue it should not impact our ability to complete our development issue nor should it impact our team velocity. Am I stating all of that correctly? Any other considerations?
One more configuration issue. I have set up several projects and workflows but for some reason this one is behaving a little differently. Once I created the workflow for this Release Management project and established the Transitions now when I press the button to transition an issue from one status to another the edit window pops open. In all my other projects when you press a transition button it simply changes the status. I must have done something differently. Can you please suggest what I may have done and need to correct?Transition screen.png
You haven't done anything wrong. You are simply using a screen associated to a workflow transition, that allows you to input information when executing a transition.
If you want to remove it, so the transition can be executed automatically, you just need to remove the screen from that transition in the workflow. Please see the documentation linked above as it will be helpful.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs