docs: add jira 3-in-a-box workflow with data connectors worked example - #1243
docs: add jira 3-in-a-box workflow with data connectors worked example#1243tsambari2 wants to merge 1 commit into
Conversation
tsambari2
commented
Aug 11, 2026
tsambari2
commented
- 3-in-a-box model overview (PM / Design / Engineering)
- Issue hierarchy, lifecycle, phased delivery, link types
- Components, labels and fix version reference
- Saved JQL filters and status transitions
- Section 10: worked example using AISERVICES-1411 epic
- 3-in-a-box model overview (PM / Design / Engineering) - Issue hierarchy, lifecycle, phased delivery, link types - Components, labels and fix version reference - Saved JQL filters and status transitions - Section 10: worked example using AISERVICES-1411 epic Signed-off-by: Tanvi Sambari <tanvi.sambari2@ibm.com>
|
|
||
| ### Engineering inbox responsibilities | ||
|
|
||
| - Creates Dev Stories per component linked to the Epic; sets `Fix Version`, `Component`, Sprint; `label: development` |
There was a problem hiding this comment.
IMO, it would be better if the PM created the high-level development stories as well. I am not clear on when the development team needs to create these stories.
There was a problem hiding this comment.
Well, I prefer that the development team owns the creation of dev stories, retaining full control over their creation and content based on our needs.
There was a problem hiding this comment.
Agree, so we would follow more or less similar approach for development stories what is followed today, If I understand correctly this process would bridge the gap between PM, Design & UI mainly.
| |---|---|---| | ||
| | `design` | Design Story | Design inbox | | ||
| | `development` | Dev Story | Eng sprint board | | ||
| | `no-design-needed` | Epic | Bypasses design gate (back-end / infra only) | |
There was a problem hiding this comment.
If you consider these new services, for current release it does not have UI. But next release it might have. How do we handle this situation?
There was a problem hiding this comment.
Perhaps you could create separate stories with clear release mappings to show target delivery dates. Since an epic can span multiple releases, we can develop and deliver non-UI stories first and UI/design stories later. What do you think?
There was a problem hiding this comment.
I agree. Epic can span multiple releases. We can create the design story under same epic and corresponding engineering stories with affects version mapping to the next release.
|
All: Please review this PR. To keep things moving, we'll merge this today by lazy consensus if there are no further comments, and tackle any follow-ups later. |
| | Label | Applied to | Inbox filter | | ||
| |---|---|---| | ||
| | `design` | Design Story | Design inbox | | ||
| | `development` | Dev Story | Eng sprint board | |
There was a problem hiding this comment.
Is it ok to assign this label just for the stories? If I am not wrong (as discussed in the scrum yesterday) even sub-tasks were asked to be labeled.
We can have this rule applied only for a story. If needed for sub-tasks as well, some kind of automation would work since I assume all tasks under a story will belong to the same category.
There was a problem hiding this comment.
Yes. you can apply the label to the stories. I will see how I can automate the sub tasks to have same label as the parent
4 participants
