Creating Dashboards means you'll need understand what your project team and management teams needs in order to present information that provides value and insights about the project.
Here are some of the widgets that I found useful in creating in a Dashboard for a Scrum Team using TFS.
Roll-Ups
I enjoy using the Roll-Up boards to show coverage across Epics, Features and Product Backlog Items. This is a great way of answering are we done yet. However, you should be careful in scope creep. I suggest using the limits to identify changes in scope for Epics, Features or Stories. Keep in mind that change should be expected. So use a threshold to monitor change.
Active by State [Backlog, Prioritized, In Progress, In Review, Done]
I use a column bar chart to show activity by state. This can definitely show how much work the team has gotten accomplished. More importantly this can highlight the bottleneck when stories haven't been created by the Product Owner or stories haven't been approved by the business.
Burndowns
Unfortunately, I inherited a project that had been setup incorrectly. So, I couldn't use the Sprint Burndown widget. Instead, I used a Pie Chart by querying off of the Sprint Iteration. I like to think of it as someone grabbing a different slice of pie until it's all gone. So, maybe this is an Eat Up Chart? [Gadunk]
Query Tiles
I utilize the query tiles to highlight items such as Blocked Stories or items that are In Review by the business. This places these items in your face so that you can focus on ensuring blockers are removed and stories In Review are moved to Done in a timely manner.
Embedded Web Page
I'm using this widget to provide easy access to the solution that is in development. Your solution is mostly likely behind a firewall for security purpose., So, if you are not working with co-located teams this may not be a good solution. Check with your DevOps & Security teams on configuration.
Challenges
As I mentioned in, I got stuck with TFS, there are two dashboards the Sprint Overview and the Sprint Burndown. Both won't work well if you have don't understand the inputs and what is driving the dashboard results. If you have more than one team working on a project delivery, which is often the case for me, then you most likely need to create two separate projects for each team.
I'm always interested in hearing about what other people are doing with dashboards. What are some of your challenges (data, tools, lack of input)?