well... i dont think its nonesense, i have Android and iOS projects where there is some shared code, i'd like to have the shared code as a subtask with two feature issue parents.
is there another better way to do it? (keep in mind the subtask is too small to be a feature issue that blocks other issues, and the two feature issues are too big to be combined as one.
I'm afraid when it comes to logical breakdowns of work, it does not make sense to have a sub-task have two parent issues. They're supposed to be there to break up the parent, which they can't do if they are part of another.
The best way to handle it is two sub-tasks, and link them together with an issue link.
It makes sense for testing, e.g. if one sub-task covers implementation of multiple stories. You can of course divide the sub-task, but sometimes it does not many sense, especially some FE restyling, where different stories just describe different sides of it (font, size, colors, positions), but you only have to do some basic checks (according to your testing policy) since they do not change the app logic.
It’s definitely not nonsense. It all depends on the perspective of the person writing the tickets in the first place. If they're from a product/user perspective... they aren’t going to know that separate features require a shared blocking task. That is common in my workplace. It’s very common in any micro architecture tbh. It’s kinda crazy to dismiss it as “nonsense”.
It absolutely is nonsense. A sub-task is a part of its parent. By definition, it cannot be part of another task because it is part of this one. When was the last time your cars front-left wheel also a part of someone else's car on the other side of town at the same time?
Blocking issues are not sub-tasks, they're effectively dependencies, and issues in their own right. They can block more than one issue and that's one of the things issue links are for.
I also think about the need to share a subtask between tasks. I am creating a huge refactoring project where several User visible functions, each being a story on its own, depend upon refactoring of a some base function that is partially hidden. I cannot demo any of those stories until I refactor the hidden part. The hidden one cannot be demoed except for showing some regression tests passing, so it is not a story/issue.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event