{"id":778,"date":"2018-11-21T09:33:03","date_gmt":"2018-11-21T08:33:03","guid":{"rendered":"http:\/\/agilerasmus.com\/wordpress\/?p=778"},"modified":"2018-11-21T09:46:47","modified_gmt":"2018-11-21T08:46:47","slug":"using-jira-and-confluence-for-scaling-scrum","status":"publish","type":"post","link":"https:\/\/agilerasmus.com\/wordpress\/using-jira-and-confluence-for-scaling-scrum\/","title":{"rendered":"Using JIRA and Confluence for scaling Scrum"},"content":{"rendered":"

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.<\/p>\n

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!<\/p>\n

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.<\/p>\n

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:<\/p>\n

    \n
  1. To make sure that you remember to handle the dependency<\/li>\n
  2. To assert if you have deconstructed your features or enablers in best possible way<\/li>\n<\/ol>\n

    Remember:\u00a0Too many repeating dependencies between teams are a sign of bad organisation<\/p><\/blockquote>\n

    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.<\/p>\n

    The output of everything is, as always with Scrum, potentially shippable increments.<\/p>\n

    Links:<\/p>\n