After a bit of fiddling about today I have just been testing a setup where a Scrum board is used to deal with various story sprints which are related to Epics (I enabled the concurrent sprint in GH labs) and a Kanban board tracks the overall roadmap view (I stole the basic idea for this from a blog post about Twitter's setup!) I have found using the simplified GH workflow very flexible as you can simply add any columns you like without having to create fiddly workflow diagrams.
Anyway, I have some questions (sorry if they are very basic!)
Otherwise the only option seems to be creating a 'relates to' issue link from each story to the Epic. I see someone has setup 'Story's Parent' (outbound) and 'Sub-Stories' (inbound) custom link types and uses JQL J-Tricks Plugin for filtering on another post but this seems like a load of work.
Rockille (point #1)>> It's almost as if I need a common 'project task' story that will have the common tasks that support each project?
Different ways to skin this one...
As to the common overhead tasks, every solution requires a bunch of infrastructure and common frameworks so the dev team can get moving. A Story, by design, solves a business capabililty. We use a zero-user story point to provide a bucket for this overhead work with subtasks as needed. I like to consider this technical debt that must be setup and configured up front on any project. No points being earned can be a heart ache for some teams, but this helps differentiate business capabilities to get a true perspective of the number of story points that the project contains. I also use subtask issue types like, "Development" and "Environment Mgmt" to help distinquish the type of work being done. In this example, tracking what the operations team does to support software development as those tasks being done by the project's architect/team lead.
As to the testing effort, we use two subtask issue types like, "Test-Manual" and "Test-Selenium". The former provides the task for the QA team member, while the latter provides the task for the developer (writes the automated code to drive a browser). See below as well...using a status on the parent issue (QA for a story) helps drive where the story is in the lifecycle while also providing a trigger for the QA team to find work.
As to the deployment tasks...consider these options.
1) Create a subtask of the story called "deploy to test".
2) Use a state in the Story workflow (e.g., Requirements Gathering-->Engineering-->QA-->Deploy-->Closed). In this case, we manually promote a story to QA once ready for testing, and tackle the deployment effort thereafter. We stay in the QA state to reach acceptance of the story. Sometimes, for a poorly coded story, we will demote it back to Engineering, etc.
Rockille (point #4) >> However, if you then view the Epic record over in Jira, the stories do not appear as sub stories.
On the admin side, assure that the "Screen" being used for your Epic screen contains the field, Epic Link. When viewing the Epic issue in JIRA, it shows a table of associated issues. I see JIRA renders 7 columns (including the Actions menu) for display. Let us know if that's not your problem. Remember, too, that JIRA only uses two levels of hierarchy - parent issues and subtasks - to form parent/child relationships. And an epic is a link relationship created between 1:M parent issues.
Deliver better and faster value to your customers with the Jira automation platform. Watch this Demo Den series below to learn how to use the new interface and set up automation rules to help your te...
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
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events