我有一個關於scrum和用戶故事的快速問題。不完整Userstory和燒燬圖表
我正在爲大學做一個小項目，我決定使用Scrum和用戶故事來解決功能問題，我知道Scrum通常是由一組團隊成員完成的，但在我的案例中，我正在使用項目主管。
我明白什麼進入一個用戶故事，指點和優先系統，如（必須，應該，可以，慣於）
現在，未來，當我來向迭代的結束，讓我們說約一半的用戶故事已完成。
一個我的用戶故事的一個例子是：
「用戶需要能夠記錄設備」
我創建的這個用戶故事的小的子任務，我已分開達到了所有的人從1個子任務，我已經達到了迭代結束。我給這個用戶故事點8
現在林不知道如果我能有這個用戶故事到燃盡圖呢，還是等到子任務完成後，增加了圖表之前。
我也想基於有可能我的任務在用戶故事已經完成了問我能立足我燃盡圖，或總是基於有多少用戶故事全部完成包括測試等
提前致謝！
有兩種傳統的燃盡圖（不會因每本身Scrum的要求）：在Sprint燃盡圖和發佈燃盡。
現在林不知道如果我能有這個用戶故事到燃盡 圖表，還是我等到子任務完成後，加入 圖表前。 這取決於你。發佈burndown的目的是瞭解剩餘的內容。該功能無法發貨，因此對此非常清楚。如果這種情況繼續發生，找出原因。
速度，你已經能夠完全完成的經驗數量，在那裏幫助你知道你應該爲下一次衝刺預測什麼。這種只是部分完成了經驗主義的衝刺告訴你不要再預測工作量。
我也想問我能立足我燃盡圖基礎上如何可以 任務我在一個用戶故事已經完成，或總是基於多少 用戶故事全部完成包括測試等 Sprint Burndown傳統上總結剩下的任務或任務時間，旨在幫助您瞭解是否需要重新協商Sprint預測（向上或向下）。
我不會推薦嘗試在sprint之外完成任務。要在發佈級別完成任務並瞭解剩餘的任務，您必須估計很多小粒度細節。你如何解決問題將會改變你目前的想法和需要多長時間會改變。毫無疑問，你現在不會做你認爲你會做的所有事情。
一些提示：
一個燃盡圖表示預計剩餘時間留在某一天的衝刺工作，所以不包括短跑以外的任何東西的數量。通常情況下，故事的評估點反映了團隊成員（在這種情況下）與故事相關的努力和風險。當一個故事分解成任務時，這些任務通常以幾個小時爲單位進行估計 - 最佳做法是任務不應超過一天或直到下一個每日Scrum的時間。
我認爲你的問題中的一個潛在問題可能是「我是否能夠計算出衝刺結束時我完成的故事部分？」。可悲的是答案是「不」。使用Scrum的最佳方式是完成一個故事非常黑白 - 它要麼完全「完成」，要麼不完成。沒有中間立場。對團隊而言，意味着什麼對他們來說意味着什麼，只要它是事先定義的而不是移動的目標。就我而言，我們使用的規則是，如果它的質量保證員是裁判員，那麼它的「可傳送質量」就是這樣做的。
如果一個故事是不可交付的，無論它是完成50％還是99％都是失敗的。沒有部分信用。如果發生這種情況，故事將以點數重新估算，然後放回積壓處，並且產品負責人有機會查看他/他是否想要爲下一次衝刺挑選它。這也是一個重新評估故事評估的好時機 - 對於一個正常規模的團隊來說，一個8pt的故事是很大的，對於一個1人的團隊來說，這是一個太大的IMO。理想情況下，團隊的目標故事大小應該在2-5點左右。最後，如果你不能完成8點的故事，這是一個信號，你的速度太高，你需要在下一個衝刺中少做點。