Hello,
What is the recommended way for fixVersion regarding all issue types that are NOT User Stories or Technical Stories, in Scrum?
We are using Versions to track what we will be releasing, mainly Stories, Technical Stories and Bugs.
But what about an epic that will be released in one version? And one that is going to be released in two versions? Do you create two epics?
Also, do you add Tasks to a release?
When a sub-task is created for a story which has already been added to a release, will the sub-task be automatically added to the same release? If not, do you care, i.e., is it important to add it to the release?
Thanks for your feedback!
Just my opinions here...
I would set the fix version on every issue regardless of issuetype where the work done under the issue resulted in actual changes directly to the release. If an epic spans multiple releases I would add the final fix version w/ a comment explaining some work was done in previous versions. A JQL could easily illustrate what work was one in each fix version. the FV isn't automatically added to the sub-tasks but could be done thru some automation if desired. That said, I would opt for not having FV on sub-tasks and assume that all completed sub-tasks under a task/story was included in the FV of it's parent.
Thanks Jack,
That's exactly the kind of answer I was looking for, and it confirms what I was thinking.
Best Regards,
Thierry
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, Jack.
What should I do when a bug needs to be fixed in multiple versions? If I specify multiple fix versions for the parent bug issue, then when I release one of them, some bug issues may have to show as in progress because the fixes for all versions have not been completed.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.