“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!
Share on LinkedIn
Share on Twitter
19