An agile approach to managing dashboard product backlog with Scrum
Here is a methodology that I used for one dashboard project managed under an agile-scrum methodology. The project scope required a 30+ person development team with four people working on the dashboard front-end components. This number was to grow so we had to find a elegant solution. 
Problem statement
Dashboards, by their structure and to conform to best practice design, often duplicate many visual elements. The bar graph that is used under an Employee Turnover metric for Department X can also be used for department Y. Both panes can be located in separate section of the dashboard. To keep uniformity of interactivity and design usually both will have the same functional requirements. What is the best way to manage this under an agile framework?
Starting under the assumption that we gather the requirement using user stories, we found that in workshops we kept asking the following:
"Is this behaviour the same as in Chart X? What about Chart Y?"
Needless to say we ended up with a matrix of functional requirements that reminded us of the worst parts of our algebra classes.
Out of this came the concept of what I call "Template User Stories". The idea is to create a generic user requirement (in user story format) and to put all the generic elements of the story that are applied to other components in this generic story. These stories are put into a separate Backlog artefact which is never to be worked on. Its main purpose is to hold the core requirements in a grouping of some sort for easy referral.
For example, the navigation elements of all the charts in a dashboard would be kept under a user story titled "Chart UI Story". If the tool supports it, we can also assign one or more categories to the element. The development team now assigns story points to this requirement, and can even to their task breakdown directly on the Template User Story. I recommend caution on this last point since the specific of a visual component implementation can vary with the underlying source and framework.
The goal here is to keep things simple and to create a structure in order to achieve the following:
- Validate the uniformity of the components
- Avoid missing key requirements for a new component
- Easily track which requirement exists in which component
- Easily evaluate the story points needed to build a new component
- Create an isolated structure in which to keep the requirements as reference
Now, when we have a Chart to create, we can quickly access the template user story and create an instance of the story and assign it to the Product Backlog. Again if the tool supports cross Backlog linking it is also a great thing to do to link the Template User Story and the actual product backlog item. With this setup, modifying a template clearly shows which component is impacted. Creating another component is also easy since all the requirements are consolidated and isolated in a stable format.
This is an on-going process, so please stay tuned for further development.
Photo source: JD Hancock