In these days of digitalisation, distributed teams and a general desire to persist information in “something that isn’t flipcharts and post-its”; more and more organisation migrate to JIRA and Confluence from Atlassian. However, JIRA does not come with direct means of scaling Scrum and Confluence does not really come with anything at all. To enable JIRA and Confluence to handle scaling of Scrum you can buy plugins for both tools but they seem to come short or limit the autonomy of the involved teams.
No matter the framework you choose to work with; the main problem is: A shared backlog of items that needs to be developed by teams that may have dependencies to each other. If that is not the case: Stop reading. Don’t even dream about scaling this setup!
Funnelling ideas through any instance of scaling Scrum is about refining and prioritising on high level to enable execution and coordination in the detail. To do this, I have found that Confluence is a well functioning container to document the refinment and collaboration between business, customers, product owners and teams to a degree that makes it possible to prioritise. This means that everything should be estimated by the involved teams, coarsly refined and prioritised.
Once an idea is prioritised and ranked high enough to be in implemented in a foreseable future it should enter JIRA as a planning item on a shared backlog as an initiative type. Business, customers, product owners and teams refined the material into features and enablers and persist them on the shared backlog as epics with reference to the actual initiative. Even though the features and enablers are stored on the shared backlog, they are refined in the context of the team who will be working on the item later. In the proces of refining the item, teams identify and report dependencies between their features and enablers and those coming from other teams. We use the built-in references “blocks” and “blocked by” to report dependencies. Dependencies should be handled by the teams themselves. There are two reasons to report them:
- To make sure that you remember to handle the dependency
- To assert if you have deconstructed your features or enablers in best possible way
Remember: Too many repeating dependencies between teams are a sign of bad organisation
When a feature or enabler is ranked for implementation by the team, it is refined into user stories that are persisted on the teams own team backlog and detailed into sub-tasks as needed.
The output of everything is, as always with Scrum, potentially shippable increments.
Links:
Thank you for your post, Rasmus. Thumbs up.
I am about to try something in Jira like the setup, you’re describing.
A thing has puzzled me: If epics and stories/tasks are not in the same backlog (project), you loose a couple of features i the backlog view, where the stories are. You can’t choose the epics from the epics panel, you can’t filter your view by epic or even see the epics as a property (only when you open the story). It’s no a biggy but somewhat annoying. Do you have any experience with that?
My own conclusion by now is, that it’s not valuable enough to persue. Thought, I’d just ask – and somplement you on you post 🙂
(2) Oh, a bonus question:
Should all Jira Projects be of the type “Scrum”, or would it make sense (or even be okay) to have the shared backlog be of the type “Kanban”?
I’m thinking, they should all be “Scrum” – and that is probably, what I am going to go for. I do however have this feeling of missing out on something 🙂
My main input is that cross-team stuff is hard to do in JIRA 🙂 As mentioned above we also used Confluence for content storage. It helps when your context is not 1:1 with the functionality of JIRA.
My main input is that cross-team stuff is hard to do in JIRA 🙂