Get certified - Transform your world of work today


Agile Project Dashboards

Bringing value to stakeholders and top management.

6 July 2011

“Scrum is all about delighting customers and delivering value to stakeholders.”

I have read this kind of statement since my first day working with Scrum in 2007. Even more, I’ve had the privilege of taking part on Scrum teams that would work motivated almost completely by this goal alone.ΓÇ¿ This is a powerful concept that not only sounds great, but can also help teams and top management adopt and support Agile practices like Scrum.

In my experience, while working closely with businesses to adopt Scrum, I’ve found that even in those cases where there is real team commitment and understanding about the quote above, and even a full commitment to apply the Agile manifesto principles, Scrum can end up way too close from the development team but not the business side.

The Agile manifesto states its main values about people, interactions and collaboration clearly. When Scrum teams honestly adopt these values, there’s a big chance that their main motivational driver will be lead by bringing value and achieving business goals. But does your Business beyond the PO really know, understand or get involved with these values? Do they have clear visibility on your team progress and project status? And most important, does your team provide sufficient information about the project progress as you go? Take a minute and think about it.

If you are a dedicated ScrumMaster I guess you’ll share your burn down charts and velocity metrics with your Product Owner.  If you already mastered the Scrum process, luckily you'll be delivering Potentially Shippable Product Increments at the end of your Sprints, which is great. But what about the Product Owner? Does he have sufficient and relevant information to do his job?

We should take a minute to think about our PO’s priorities and responsibilities. Many companies end up with former Project Managers running this role. If that’s the case, there is a big chance that the PO will be responsible for managing costs, tracking project schedule, people, risks, follow up on features for commercial releases, communicating, etc. In many scenarios this kind of information won’t be necessarily revealed during a Demo, during the Sprint planning, or even on the Retrospectives. If that’s the case, there's a chance that the team will be disrupted at some point to be asked about this data.

The question that arises here is: does the team have sufficient information to help the PO identify some of these variables and indicators? Can the Team provide more business value, apart from the Product Increment at the end of each Sprint? Can we take advantage of our Scrum ceremonies to compile some of this information in a clear and visual Dashboard?

Sure they can!

The aim of this article is to bring to the table a consolidated Project Dashboard layout that could be easily maintained and updated by the PO with day-to-day and well-known information the team can provide, so that he can grab stakeholder’s and top management attention and support while providing an updated clear picture on the Project’s health
The kind of Dashboard I suggest here is pretty much the layout I use in my projects, and can easily suit a wide audience of “chickens”. Even when some project sponsors might not be aware of metrics like Velocity or concepts like Story Points, they will surely understand the picture as a whole, while leaving up to them the choice to take a deep dive into the details.

Setting up the dashboard

So, what information should we present here and where is this coming from?

If the PO is the person responsible for communicating the project status, some of this variables will (and should) be identified by him/her, based on the feedback he gets from the Team. And when is the right time the Team can provide advice or feedback about these variables? We’ll see.

The dashboard contains the following set of indicators (ΓÇ¿Note that this is just my approach to Agile Project Dashboards. You can always set your own layout according to your needs):

Project progress schedule - Indicates time elapsed over total time until a given date expressed in %. ΓÇ¿That reflects actual process of the project in terms of time allocated to the project. If you have an estimated Product Backlog and planned Sprints, this could be the relation between Completed Sprints over Total SprintsΓÇ¿ΓÇ¿

Delivered Business Value - If the Team has an estimated Business Value per Story (Business Value Points) in your Product Backlog, this is the Sum of delivered Business Values Points (DONE User Stories) over the total Business Value Points estimated for the entire Product Backlog. This reflects the actual progress of your project in terms of business goals achieved. ΓÇ¿The total amount of delivered Business Value points is validated with every Sprint Demo

Product Release burn up chart - This is an essential performance metric to show to any project stakeholder. You could show instead the well-known Product Burn down but,  in my opinion, the Product Release burn up gives a better perspective on “how much we still have to climb” to get the product done. It also easily reflects and brings to attention any possible Product Scope change during the project.ΓÇ¿The Sprint Demo is a good moment to provide feedback to the PO and update the Product Backlog chart depending on Stories delivered in the last Sprint. Any Scope change should be identified during the Sprint Planning meeting.

Team performance - This is the actual estimated and previously achieved Team Velocity, depending on Story Points delivered and calculated as usual.

Delivered SP - ΓÇ¿A simple bar chart indicating estimated (committed) vs. delivered Story Points is a very convenient and clear information radiator to track estimation accuracy and even to detect other hidden issues like potential risks.

Highlights - ΓÇ¿By definition this is a wide concept that should enclose the most relevant events that came up during the last Sprint. This does not necessarily have to be linked to Business value, but with any relevant situation that might be of interest to the Dashboard audience.ΓÇ¿The Team can point interesting facts to the PO during the Demo, or even in a retrospective meeting.

Risks - ΓÇ¿Identifying Risks is an exercise that almost every Team member should try to keep an eye on. Or at least assist on identifying potential issues.ΓÇ¿The Sprint Planning Meeting is a great moment to express concerns, and to identify risks. Making a Risks Matrix is an activity that could be easily performed collaboratively between the Team and the PO ).

Next steps - ΓÇ¿Just like when detailing Highlights, Next Steps should communicate the most relevant future actions.  ΓÇ¿The Sprint Planning Meeting or the Sprint Retrospectives are good places where to get this from.

Timeline and release plan - ΓÇ¿At the minimum, this timeline should reflect Sprint Start Dates. If you do have some planned milestones or releases in your project, this is where to show this information. You could easily keep track of achieved milestones and make notations on relevant dates.

Overall Project Status (Red – Green - Yellow) - This indicator should be identified by the PO, or whoever is capable to estimate status in relation with a wide spectrum of variables, project goals, objectives and risks. This should be easily identified based on feedback the team provided during Sprint Planning, Demo and Retrospective meetings, and it would be wise to be the last indicator to be defined on the Dashboard.

Stick to the Agile Manifesto and keep in mind that the PO should invest time on building this kind of indicators only if they bring some value to your organization.  And in case it does, of course you should adapt it according to your needs (add or remove indicators as needed). By providing a unified and concise Project Dashboard you will keep your audience updated and focused on the topics you need them to keep an eye on. In case you don’t already have this kind of information radiators, I strongly suggest trying this approach and see for yourself if improves your communication with both Stakeholders and the Scrum Team.ΓÇ¿And please drop me a line and share with entire Agile community know your findings, tweaks and improvements to this Dashboards!

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: 5 (1 ratings)


Chia Wei Cheng, CSM, 7/6/2011 9:37:47 AM
Thanks for sharing. Very useful guide for Product Owner. I am interested in Business Value Points. Does it really estimated by the team? Does the team have more business sense than PO?
Leopoldo Simini, CSM, 7/6/2011 10:00:31 AM
Hello Chia Wei.
I'm glad you found it useful.

When I mention ΓÇ£Business Value Points in your Product Backlog", I refer to Business value estimated by the PO. This type of estimation could be easily set for large user stories or themes.
And yes, the PO is the right person to assess this estimation.

Additionally, helping our business people to work on estimating business value will also help them on prioritizing stories.

BTW: It seems the article was not published with some graphics I included to illustrate each case. IΓÇÖll soon post a link to the full article in PDF , in case we canΓÇÖt update the article here.
Chia Wei Cheng, CSM, 7/6/2011 11:14:45 AM
Thanks Leopoldo for explaining. I re-read the article again and find I actually misunderstood that Business Value is estimated by the team, my bad...

I am particularly interested in Business Value point as I aware of this artifact (although it is not a standard scrum artifact) but I actually have never seen this. What PO do was normally just sort the product backlog based on priority or business value without any points given. I think it will definitely helpful if we have estimation based on business needs transparent to developers. So that everyone know how a user story weight over the overall project business value point. To justify the importance of their hard works.
Barry Simmons, CSM, 7/6/2011 3:04:15 PM
I am interested in knowing what method you are using to present the project dashboard to the stakeholders. For example, do they have access to your Agile application life cycle management tool whereby they are able to view this information or do you provide it to them in a spreadsheet or other document? Thanks.
Leopoldo Simini, CSM, 7/6/2011 3:29:50 PM
Hello Barry
Fortunately my Agile application life cycle management tool is still the old school scrum dashboard full of postits :)

The Project Dashboard I present in this article is done using a simple Microsoft Excel Spreadsheet. Information to generate these metrics and graphs are compiled by the PO, and the Project Dashboard is forwarded by email, printed in full color or (much more convenient) reviewed in a timeboxed meeting with the Stakeholders.
It is a pity they didnΓÇÖt include the images in the article. This way you could have a clear picture of it. But stay tuned, I will add a link to the full article tonight!
Robert Brutus, CSM, 7/7/2011 11:58:16 AM
I have a quick question regarding a situation and I promised my group that I would ask this question in the Scrum Alliance forum.
I am currently playing two roles in a project: Scrum Coach and Team Leader. I have coached and designated a neutral person to play the role of Scrum Master.
The project also has a traditional Project Manager. This person uses Microsoft Project and is currently having an issue on how to report work items not completed during one iteration. As a scrum team, we move the item to the backlog and allow the Product Owner to re-Prioritize the items. It the work items is urgent or has high priority we move the work items to next iterations. The Traditional Project Manager issue is: an Iteration cannot be reported completed since items did not get completed. How does the item be shown in her Project.

Leopoldo Simini, CSM, 7/7/2011 5:05:47 PM
You can read the full article (with images included) here:

** English version (PDF) **

** Spanish version **

Leopoldo Simini, CSM, 7/8/2011 7:55:01 AM
Hello Robert
Why you PM need to keep using MS Project to report project progress? Is this a corporate standard or requirement? In case itΓÇÖs not, maybe she could start thinking for alternatives to it. In this article there are some simple graphs that could help her. Reporting the Delivered SP bar chart she could easily compare committed SP vs. delivered SP for each Sprint. The burn Up chart can also reflect your current vs ideal trend. And if you do estimate Business value per stories/themes, then you have the full picture of what the Team has for the last sprints. You can take a look at the graphs here:
Nicola Lovadina, CSM, 7/18/2011 2:18:58 AM
Hi Leopoldo, very good article, i'll propose to do the same to my PO and i'll keep you posted about the progress.
Andreea TOMOIAGA, CSM, 7/21/2011 8:35:32 AM
Hi Leopoldo, in my opinion this article is very valuable and the ideas here are worth to apply especially in organizations where these reports are valued. Agile practices prove to be very useful to apply internally in teams for example estimate using velocity but if management needs classical reporting and relies more heavily on RUP then I think converting between the two worlds is useful. For example converting a product backlog in a project plan and think in matter of user stories and not tasks is a possibility to present the project functionality and percentages of completion for each one in an MPP format. The dashboard structure to measure and represent project progress is a very useful tool to report progress in organizations that value traditional methods of monitoring and reporting.
Saurav Kumar, CSM, 7/23/2011 7:41:35 PM
I understand the desire for agile project dashboard to collect various project data however my main concerns with the proposed are:
1. As part of Scrum team, we make sure that we update ToDo estimate on a daily basis each sprint. The beautiful thing about this is it allows team to focus on work which needs to be done. This also create great amount of transparency to all stakeholders involved including chickens.As a scrum team we also create and update sprint burndown chart on daily basis which indicates the progress of tasks signed up for current sprint. Do you think it will be good practice to ask team members for any additional metric data as part of Scrum?

2. Most of the scrum teams do adopt tools such as Version one which can generate sprint burndown, velocity metric, sprints history chart etc.Scrum masters and PO can use it for their, team reference and also for status updates to other stakeholders including chickens. This lets team members focus on the actual deliverables in the sprint.

3. Creating dashboard with fancy data tends to facilitate micro management sometimes. My experience with this is sometimes Po or scrum master or team lead(this role is very difficult to get away from:)) who is managing this sort of dashboard tend to ask for some more data to make the report fancy so that he can grab stakeholderΓÇÖs and top management attention. I think this is against the very basic principle of scrum where the team members are mostly supposed to know ToDo for stories/tasks they have signed up for. Also we need to be aware of a fact that whatever we do it should suit a team who is working on project rather wide audience of ΓÇ£chickensΓÇ¥
3. Coming to your another point "some project sponsors might not be aware of metrics like Velocity or concepts like Story Points" , I think that its always better to educate stakeholders on scrum concepts rather than presenting them data which is kind of inline with what i s presented as part of traditional SDLC process like waterfall.
This will also help scaling Scrum across organization.

Please remember that Scrum facilitates self organization which is a key for its success.
Leopoldo Simini, CSM, 7/25/2011 8:55:29 AM
Hello Saurav. I agree with most of your comments. But keep in mind that this article suggests the PO is responsible for this dashboard, not the Team.
The PO should grab information from our current scrum ceremonies, in order to not disturb the Team's focus. The SM is responsible for drawing the line and set the limits in case the PO tends to try doing some micromanagement :)
In case you already have an electronic tool like Version One then maybe your management already has some place where to look for metrics; or maybe not. This dashboard is intended to be an executive summary for top Management. And is a guide for your PO on how to get relevant information and how to effectively summarize and communicate it.
Saurav Kumar, CSM, 7/26/2011 8:55:36 AM
Thanks for your reply Leopoldo. I agree that this is a good way to communicate executive summary to top management which is really required in any Org:). I was just trying to bring/expose in some of the Cons of this.
Ajit Bhanot, CSM, 8/1/2011 3:30:06 PM
Very Crisp and Clear, how are the testing statistics reflected? For example if Testing is being done with the help of an automated tool or if the test results are being recorded in a testing tool? The open defects would reflect the technical debt being carried into the next sprint. ThoughtS?
Michele Cresmen, CSM, 8/30/2011 12:26:27 PM
Leopoldo, this is a great article and very timely for my situation. My client is just starting their agile journey and has a very intricate and rigorous project health reporting system based on waterfall processes and deliverables. One of the things IΓÇÖm providing input into is this type of reporting from POΓÇÖs to their managers (and their managers, etc) for agile projects. Looking at the dashboard in the PDF, the burn up is for the Product Release. Upper-level management would be interested in the full timeframe theyΓÇÖve allocated to the project and seeing a burn up for the entire project. However, as we know, sizing of items in the backlog far into the future is vague and will certainly change as it rises in priority and gets further attention from the PO in breaking out themes/epics that the team can size more accurately. Do you have any thoughts on how you would adapt this for an entire project that might be multi-year and have many releases?
Tulio Oliveira, CSM, 9/19/2011 2:29:30 PM
Congrats Leopoldo.
In my company we use a dashboard called "situation wall". It's works like your example. Do you think good show defects/testing statistics and estimated accurancy to PO?
Dean Hiller, CSM, 10/28/2011 7:36:19 AM
Hi Leopoldo, it happens that we have developed a dashboard at If you wouldn't mind I would love to discuss how I could add more to the dashboard page and where I would put it. Later I can make things smaller but first I want to get all the main items on the page. I think I have a few of the ones you speak about already. Shoot me an email at dean at and you can have a one free team(10 people) lifetime license for your help!!!
Niels Trusbak, CSM, 11/30/2011 5:00:32 AM
@Leopoldo, could you share the mentioned graphics, please? Many thanks.
Seema Sonkiya, CSM, 5/24/2013 4:28:17 AM
Very useful article

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