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潛在的問題。