Story Points
Story Points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.
Story Points are a relative unit of measurement. The keyword here is relative. A Story is relative in term of Story Points to other Stories.
When we estimate Story Points, we always consider all the work that has to be done. This includes designing, coding, testing and integrating. We also take into consideration the definition of done. If we have special tests, we consider them as well.
We calculate the velocity of a Scrum Team by combining the Story Points from all items that were done in the past, or ideally, an average of the past several Sprints. This helps us determine the capacity our team can handle during the next Sprint.
This may help the Product Owner to calculate the completion date of the Project. Remember the velocity of a team may change in time. It needs several Sprints to get it stable.
When we estimate with Story Points, we consider the amount of work, uncertainty, risk, and complexity.
Estimating with Story Points is NOT mandatory.
Burndown Chart
(add example picture)
The Burndown chart shows how much work is left to do. It goes down as we progress and complete Stories. We have 2 lines, one is the ideal path and the other is what actually happens.
Burnup Chart
(add example picture)
The Burnup chart shows the complete work and the total work. The completed work starts from zero and it gets up. This chart shows any changes in the scope of the project. The scope is the total amount of work.
This chart is used to clearly show changes in scope. If the scope hasn’t changed by much, we would go with a simpler burndown chart.
Cone of Uncertainty
(add example picture)
The keyword here is uncertainty. The cone represents the fact that in the very beginning of the project the uncertainty is high. The more we do, the more we reduce uncertainty. This is done because as a Scrum Team we need to give estimations. That’s going to be much harder at the beginning of the project, as opposed to the middle or the end of the project.