This is a more useful version of the commonly used sprint burndown chart, because it shows both the Task Burndown , on the left had scale  and the story burndown  on the right hand scale 
Delay in completing stories, as shown in the example below, indicates that the team should be looking for ways to finish stories earlier in the sprint. This kind of sprint pattern is often referred to as 'mini-waterfall', as the testing (and validation) is left to the end of the sprint.
This article shows how to interpret a Sprint burndown 
Note:The realtime chart shows intra-day state of work.
As with all charts, you can click on the lines to show the User stories or tasks
The Burndown shows the state of work on each day of the sprint. So, if the team takes in a new story or adds tasks during the sprint then this will be shown on the day that it was actually done.
Note: SenseAdapt only counts the completion of a Story when it is moved into the 'Done' state. It does not count a story that is '80% finished' i.e. it follows the principles of Scrum
Some Sprint burndowns, e.g. in TFS, will retrospectively adjust the amount of work remaining.
For example: if the team has 110 hours of work on day one of the sprint, and then adds 40 hours on day 3 then TFS adjusts the first day effort up to 150 - see below.
Whereas the SenseAdapt chart (above) will leave it at 110 hours on day one and add 40 hours on day three
In TFS both Stories and Tasks can be allocated to a sprint. In the example below.. Some of the tasks in PBI 4139 were completed in Sprint 3 - however, the PBI was not completed in Sprint 3 and so has been moved to sprint 4 with task 7086.
SenseAdapt will show the PBI #4139 and Task # 7086 in the burndown for Sprint 4 It will show the PBI in both sprint 3 and sprint 4 - but only show the reduction (burndown) of story points when it gets to 'Done' in sprint 4