Hi all,
I already used the search function, trying to find an answer to my question but so far I didn't find a good solution. Hopefully, one of you can help me :-)
We have a project with 5 scrum teams, each of them having its own backlog and own 2 week sprints. So the granularity of the backlog items is < 2 weeks. Let's call such Sprints "Team Sprints".
With our stakeholders we do a 3 months planning. So we discuss which features shall be implemented, e.g., in Q4 2018. So basically, this is the planning for a 3 month Sprint. Let's call such Sprints "Master Sprints".
What we try to realize is something like this: There is a product backlog which contains high-level requirements with a granularity of max. 3 months. We create a Master Sprint for, e.g., Q4 2018. From the product backlog we drag&drop the features from the product backlog to the Sprint. Afterwards, each feature is broken down into tasks with a granularity of 2 weeks (so they fit into the Team Sprints). As a next step, the tasks are assigned to the teams. Based on this, the teams can organize there Sprints completely in own responsibility. Thus, the teams assign the tasks to their Sprints and brake them further down. On the master scrum board, we want to see the progress of the 3 months features, including the derived tasks. On the team boards we want to see the progress of the derived tasks and their subtasks.
My first idea was to use Epics for the Master Sprints, which can be broken down to Stories, which are assigned to the teams. The teams brake down the Stories to sub-tasks. However, in Jira Epics cannot be assigned to Sprints (which makes sense considering the Scrum theory). Next idea was to consider the Master Sprint more as a Software Release. However, it is not really comfortable to assign Epics to a Release. In addition, their isn't this nice Sprint board, which shows the progress of tasks and their sub-tasks in a structured way. I ran into similar issues when trying to find a solution using the Kanban board.
Current solution idea: Stories are used to define the high level requirements, which are then assigned to the Master Sprints. These stories are broken down to sub-tasks, which are assigned to the teams. The teams do the following for each sub-task: clone the sub-task, convert cloned sub-task to a Story, which then can be used for the Sprint planning of the Scrum team. These stories are again broken down to sub-tasks. The connection between the "master sub-task" and the cloned story is visible by the "clones" relationship. If a team completes such a cloned story it also has to set the master sub-task to complete, so that the progress is visible on the Master Scrum Board. Advantages: We can see the progress on two different levels (Master Sprint level and Team Sprint level) and we can do estimations on two different levels, which allows to determine the overall velocity as well as the team velocities, allowing a better planning on product and team level. Disadvantages: The manual steps (cloning/converting the sub-task and adapting the state of the sub-task to the latest state of the cloned item) are quite annoying and the "clones" relationship is not as nice as a real hierarchy (like Feature->Story->Sub-Task instead of Story->Sub-Task->Cloned Sub-Task converted to Story->Task).
Is there any better solution? I know there is this Structure plugin which would allow to define a better hierarchy. However, a) I'm not sure if it is possible to introduce this plugin in our company, and b) I don't know if the different hierarchy elements can used for Sprint planning and progress visualization in the way we need.
Sorry for the long text and thanks a lot
Chris
