Scaled Backlog-On-A-Page

The Value

Quite often in the world of agile, the simplest questions are often the most difficult to answer:

• “How close are we to releasing?”
• “How large is this feature, relative to work we’ve done previously?”
• “Is the team investing their time in accordance with the priorities we originally laid out?”

We often try to unearth these insights using extracts of data from digital work tracking tools such as Jira, Trello, or AgileCraft to name a few. However, it can be difficult to aggregate this information using conventional means. There can also be inconsistencies in the way the tool is used which can skew the results. What if there is poor hygeine or data quality in the system, isn’t that something we would also want to see?

How can we quickly move past these limitations, and start having informed conversations around the state of our portfolio?

Hypothesis

We believe
that visualising a hierarchy of work that traces a story all the way up to it’s product/feature
and aggregating the progression of work from the bottom-up
will enable managers and leaders to understand the true state of progress in their programme of work
We’ll know we’re right when said leaders can use this hierarchial view to see where progress is made
and effort has been invested.

Method

1. Identify scope of analysis using JQL query in Jira, or through collating a list of boards/projects on other platforms
2. Extract a data set using the platform's API
3. Cleanse the data using a KNIME script
4. Reorganise data to identify a fully traceable heirarchy for each user story, and use that to determine the true size* and progress of each layer through bottom-up aggregation
5. Visualise the results using the d3.js javascript library

* Note: the sizing of each user story can be calculated using lean principles (uniform sizing) or through relative estimation (non-uniform sizing)

Insights

After trialling the Magic Wheel in several environments and backgrounds, from large-scale SAFe PIs to individual flow-focussed Kanban teams, there have been several key themes identified once placed in front of the team:

• More often than not, there is a large portion of low-level user stories that have not been tagged correctly with Epics/Features/etc. This means senior management are undervaluing the amount of work delivered by their teams, and their forecasts were built using incorrect assumptions.
• On occasion senior leaders identified portions of their backlog that had little correlation to the set of priorities they had decreed at their last large-scale planning event. In one case, the team had 60% of their backlog allocated to the feature with the lowest importance from a priority perspective.
• When end-users had a chance to interact with the Magic Wheel they were able to overlay their context and anecdotes to identify some interesting delivery patterns that would otherwise have remained hidden.

Conclusion

By taking the time to decompose and rebuild a data source from the ground up, where most of the activity sits, it is possible to aggregate that information into a meaningful ‘on-a-page’ visualisation that resonates with teams and senior leaders alike. Even if there is a belief that data quality is poor from the onset this can still lead to some interesting conversations.

If you'd like to know how this visualisation could be implemented in your organisation, feel free to contact us!