How to Build a Dashboard Using Agile Methodology [Part 2]

Here is the second part in my attempt to provide the basis for an agile approach to dashboard development.

In Part 1 we saw that there are both data and visual elements to a dashboard. In most cases, both these elements must be considered in tandem, like a graph getting populated by monthly sales revenues. Both design and content must be built together incrementally to deliver agile value.

Tips for creating Dashboard User Stories

Continuing on our notions from Part 1, within the design and the segmentation of the delivery, I want to spend a bit more time exploring the type of stories we will create in the sprint.

I suggest to regroup the dashboard into analytical elements that encompass both the UI and the data aspect. An analytical element is like a scorecard with alerts and an accompanying trending graph that reacts to user selecting a kpi in the scorecard. I see this as a group of visuals that supports a user story like “I need to have an overall view of my key metrics, and trending on demand to observe the pattern in the data”. Honestly no user even told me something that clear and concise, but you get the idea.

Another story could be “I need to export the page to PDF”. That would be a functional story in the way that it implements a feature of the data that has nothing to do with data. The same would go for stories such as “I want to access my dashboard with an iPad outside of the company Intranet”.

Now that we have a list of stories I want to expose another concept. Depth vs. Breadth.

Strategy I: Focus on Depth

With this approach, there is a focus on the sprint to fully build a specific analytical set of visualisations for the user. For instance, a graph with the correct thresholds and 3-4 levels of drill on the metric. The user might be able to filter the metric against a specific set of filters, like Country or Product Type.

The development team would focus on building features to drill, slice and dice the metric within the analytical set of visuals. For instance, the scorecard and trend mentioned above would support drill-downs, and the graph could support predictive trending, etc. The focus is on a limited number of graphical element to support a limited number of well fed metrics. Here maximum value is obtain when the same graphical components can support many metrics.

The requirement for this is the strategy is that the metric behind the visualisation element must have a lot of detailed data available across many dimensions. For instance, we have the “Nb. Widget Sold” metric, but we have it per day, per department, per market, per client etc... The data maturity behind the metric needs to be quite high.

On this we focus on exploring the metric’s behavior and can provide more insight, more depth, on its context. We can use this strategy when we are deploying metrics with a lot of dimensions and historical data available.

The downside of this approach is that it will lack in breadth. That is, you might only have access to sales metrics with 3 years history, but won’t be able to make the correlation to your costs, sales points or any other metrics that are not in the dashboard yet.

We naturally go into this strategy when we are building tactical or operational dashboards, because typically the back-end team focuses on a few siloed metrics that have the same data foundation (conformed dimensions).

Strategy II: Focus on Breadth

The next strategy is to build the first topmost layer of the dashboard. That is, build many visual elements to give context, while not building any “depth” to the metrics.

For example, we could have a set of 20 KPIs at a Corporate level with YTD values, but no detail per month nor detail per product lines. This is used when the metric’s detail is not available yet, but there is still summary information available. It is also naturally used to do a quick prototype and the data is a mashup sourced from excel files and silo databases. i.e The data maturity is low.

A point to note, I do not imply that the front-end team must always react to the whims of the ETL/modeller duo. This is a viable strategy to adopt in order to lead the development of the dashboard and have the back-end team follow. It is a reality that oftentimes the data wrangling is broken into sprints due to data availability and complexity. This in turns forces the front-end team to make due with the data that will be available during the sprint.

In Resume

There is always a game of give and take between providing depth of analysis or breadth of context within a dashboard project. When the dashboard is tactical or operational this is rarely a problem as the scope of metrics is often smaller and deeper, but at strategic level the users might want to have a “lay of the land” rather that a 10,000 foot data pit on a single metric.

In the next part, I will try to integrate these notions into an agile project delivery. We will try to find how to best develop sprint that integrates with the back-end team while delivering value for the product owner and his users. It is here that I will integrate the design steps and the building effort together.