Scrum team运行的好与坏，其中一个重要的指标是在某一个或多个release中，这个team的storypoint burn down chart可以很好的反映出来。在一个sprint的开始阶段，整个team要做一个sprint的planningmeeting。也就是说将这个sprint要实现的功能相对应的userstory放到相对于的sprint中。同时每一个userstory都有一个相对的难度系数—point。所有的userstory的point会反映在storypoint burn down chart上。在这个chart上一般有以下几个数据构成。
1. Planned User Story Point;
2. Sprint Start and End date;
3. Sprint lasting days;
4. Story Point Guide Line;
5. Story Point Burn Down line;
6. Story Point Burn Up line;
7. 在某一个时间点上Story Burn Down Line上的值和StoryBurn Up Line上的值的总和为Planned User Story Point;
根据上面的描述我们就可以生成关于该数据的二维座标如下图所示，
该图显示，在某一个sprint中，该scrumteam总共plan了24个point。因为该sprint还没有开始，所以StoryPoint Burn Down line 和Story Point Burn Up line 没有在该图上显示出来。但是随着时间的跟进，两条先回生成出来。同时生成的原则是每天生成一个点，然后将各个点连接起来构成一条线。
接着看一下在sprint中/后期的时候，类似的图会是什么样子，
从上面的Story Burn Down Chart可以清楚的看到每一天中Story总体的进展。同时也可以看出来该scrumteam运行的情况是十分良好的。为什么这么说呢，大家先看看UserStory Burn Down 这条线，随着时间的流逝，每天都有相关的story被完成后关闭。而且关闭的时间跟Story PointGuide Line的时间很吻合。
下面看一个相对来说Scrum Team运行的不是很好的例子，先看一下相关的User StoryBurn Down Chart，如下图1/图2所示。
对于图1所示的scrum team来说，在sprint的开始计划要做12个point的story，但是在sprint的中期的时候又加进来了若干个story。进而导致user story burn down 烧的很难看。对于图2来说，在sprint中期几乎没有相关的story完成，而到了sprint的后期，几乎所有的story都被完成了。对于图1反映的一个问题是，对于一个scrum来说，最忌讳的就是在sprint的中期，本来已经计划好的sprint，突然往该sprint加任务量。对于图2反映了一个问题可能是计划的story的粒度不是很好，也可能是在开发或测试阶段有什么问题block住了该story的完成。这时候做为一个manager或是scrum
master就应该站出来提出这个scrum team潜在的问题。