Get certified - Transform your world of work today


Are We There Yet?

Creating Visibility by Leveraging Dashboards

25 November 2013

To know where we are, whether we are treading along the right track, how far out we are from our destination either in life or in a project -- these are questions that most of us have struggled with at some point. When it comes to our own lives, introspection as a tool has been popular over the eons. For projects, specifically software projects, the challenges are multidimensional. Given the fact that in a typical project, multiple team members -- either co-located or distributed -- are involved, the task of creating the right amount of visibility for all stakeholders manifests into a complex challenge.

This complexity increases manifold when the people seeking visibility into a project's status are either the bosses or the clients, which again is what happens more often than not. This reality is based on the fact that when one's boss demands a status update, he'd better have one.

Agile talks about "people over processes" and "collaboration over documentation." This does work, but when the demand for visibility starts interfering with the normal functioning of a team, in the form of requests for frequent meetings, quite often at times that are odd due to working in a distributed team, maybe it presents an opportunity for evolving Agile and Scrum and begin considering tools for assistance. Selection of tools need not be something that we bleed our budgets to pay for.

In this article, I discuss leveraging JIRA and creating appropriate dashboards that can perhaps be used for ensuring enhanced visibility into progress and for deriving metrics such as resource use, either on a daily, weekly, or sprint-by-sprint basis. This is a strategy that has saved me and my team a significant amount of time and effort and provided us liberty to focus on churning out appropriate business value sprint after sprint, instead of being expected to attend a set of repetitive and mundane status calls.

I would, however, like to emphasize that this is not a silver-bullet solution. Like all complex problems, the solution in the form of the specific dashboards we created in JIRA and worked for me and my team -- it might have to be adapted to fit your own specific situation. The intent is to offer a starting point with a couple of dashboards that serve as examples of leveraging a simple tool like JIRA. I also assume that the project you are working on already follows Scrum or some other implementation of Agile that is based upon an iterative development model, and that it might just need some tweaking in order to open windows for enhancing visibility and transparency augmentation.

Stakeholders seek visibility into the current status of a sprint. As discussed, they are mostly decision makers (the management), either at the client side or in our own organizations. Although it might appear demanding to a team member when asked for frequent status updates, one needs to empathize with the concerns of management, too. Projects are mostly a part of a bigger work flow or organizational initiative, wherein the success or failure and adherence to timelines might impact the rollout of a strategic feature or strategic offering. In the absence of easily accessible information or metrics, they have no other option but to demand frequent meetings that might assist them in making the right decisions. At times, they are inclined not to navigate through a bunch of complex charts and reports. It is probably a lot more convenient for them to simply ring people up and seek answers. We wanted to empower our decision makers by providing them the right amount of information in the simplest possible form. Since our team already used JIRA for tracking user stories and creating sub-tasks for respective stories, we decided to create reporting dashboards.

Each task that needed to be completed for conforming to the Definition of Done for a story was added as a sub-task to the original story. As a part of our efforts to emphasize that the information captured in JIRA is going to act as the data library for our dashboards, we conducted multiple meetings within various Scrum teams of our project to try to encourage people in being diligent in updating JIRA.

Dashboard 1: Where are we? The current status

Driven by the data libraries created from the data captured in JIRA, the following is a snapshot of the contents of the dashboard we created for providing a single-screen sprint-status snapshot for our project.

Figure 1: Sprint Status Dashboard

All the fields in this dashboard are created based on the data that has been provided for stories and tasks in JIRA. We found the "Status" field of particular use as it clearly highlighted which tasks have an impediment during the current sprint as well as the action item pending for removing that impediment. All the tasks and stories linked back to the original Story/Task in JIRA, so that the stakeholders can get to more details about a specific item that they are interested in.

Dashboard 2: What did you do? Team member status

Once again, the question might elicit a wince from most people, those reading this and those of whom this question is asked. It has been my observation that the party asking this question is mostly just disconnected from what the team has been doing on a daily basis. This situation might be a good candidate for referring to the ages-old story of the Chicken and the Pig. The Chicken is generally the one asking the questions and, as always, it's the Pig who's getting slaughtered, albeit figuratively in this case.

In order to save the Pig, and the day, following dashboard was created for highlighting the work done by respective team members on a story and task-by-task basis for every day of the sprint.

Figure 2: Team Member Dashboard

This particular board can be created at another level of stronger granularity wherein the specific focus is on an individual developer. A simple representation of "To Do," "In Progress," and "Done" with tasks that are updated on a daily basis can be represented in a manner similar to the one shown below. Please note that this borrows heavily from the Kanban school of thought.
Figure 3: Team Member Dashboard (individual)


A stakeholder who wishes to gauge the progress, either for the entire sprint or for a particular story, to get a feeling about where the team is simply needs to go ahead and visit the Sprint Status Dashboard and obtain that information. For team member-specific status updates, the Team member Dashboard template might be used.

In order to ascertain that the progress can be quantified as accurately as possible, it needs to be emphasized that the tasks identified under a story for getting it to the "Done" stage are as granular as could logically be possible.

Having a task that takes anything more than a day might not be a very good idea in general. There might be exceptions to this in some specific cases and scenarios, but, more often than not, tasks that can be measured in hours offer progress insight that is easier for everyone to grasp.

The effort involved in creation of such dashboards or, for that matter, tasks with such granularity might just seem like overhead. However, if one were to consider the benefits of following this approach, it may be worthwhile to invest in it.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3 (2 ratings)


Nice article Sourabh. You mentioned it correctly "Projects are mostly a part of a bigger work flow or organizational initiative". Dashboards will give us an overview of where are we.

I personally believe that, if you have a smart tool that generates your dashboard reports without any / minimal manual effort then nothing is better than that. Problem one may face is with people who are very report and chart oriented, they will keep on asking you for multiple reports, charts, data etc. On a different note 'burn down' charts provides us more useful information for a sprint as compared to any custom chart, report.
Sourabh Goel, CSM, 11/26/2013 5:33:55 AM

I agree. Having these dashboards generated by a tool is the right way to go forward. The tool that we used to configure these boards in our projects is the ubiquitous JIRA. Using a plugin like Greenhopper in JIRA(now called JIRA Agile) one can configure similar boards.
David Lowe, CSP,CSM, 11/28/2013 2:22:21 AM

Thanks for the insight into your world. I can see that the sprint status dashboard could be useful for the team, stakeholders, other teams, etc. However, I'm curious to know what the aim of the team member dashboard is? Why do you feel the need to publish that information? Surely your scrum board shows what people are working on NOW?
Robert Kalweit, CSP,CSM,CSPO, 12/3/2013 6:20:32 AM
Nice article, on "reporting in an agile world".
I have to agree with David, though, and am curious on the detail-level required to report to stakeholders.

With the PO as the "single-wringable-neck", a status report on task-level should not be required. If it is, I would assume, the stories are too big, to show (and report) incremental progress.

I've worked with JIRA Agile for years now (first as ScrumMaster, later, after a change, as PO) and dare say: As an ScM I was constantly helping the team focus on the tasks for the top-priority story. As a PO I did not care AT ALL about single tasks. I only cared about completed stories (and I told the team constantly that a half-finished story to me was as good -or useless- as a not-started story).

JIRA Agile also offers a nice overview on every level: Epic, Stories within an Epic, Tasks within a Sprint. For us it reduced the manual spreadsheet-reporting effort to zero.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up