Reporting completion points in daily standups

Why report anything at all in a Daily Scrum? Its purpose is for the Developers to come up with an actionable plan for the next day of work which takes them closer to their Sprint Goal. If they can't inspect and adapt properly because of reduced transparency arising from inadequate granularity, then that's the problem to be solved.

Thanks Ian. Yes, it is true that DSU are not primarily focused on reporting but for the burndown chart points are indeed reported in DSU so the progress can be tracked. In that context, how best to report the burned points?

Where in the Scrum Guide did you read anything about a burn down chart? If your team is choosing to use a burndown chart then they should determine how it is used. 



Having said that in the times I have used those charts we used it to show the burndown of completed items. We only estimated the item representing delivery of value to the stakeholders. So the burndown is not expected to linear. If you are working on a 20 point story, it is known that it could take multiple days to "burn" that item. Plus you have to remember that you are burning an estimate that was made without full information. It is not a measure of success. It is an indicator that items producing value are meeting the definition of done. 



The Daily Scrum (not the Daily Standup) is to discuss new information uncovered and plan work accordingly for the next day. It is not a status meeting in any way. You acknowledged that but then said that a chart that shows status is "indeed reported in DSU so progress can be tracked". That sounds a lot like a status meeting. 



You asked how to report burned points. In my opinion there is no need to report them because they are irrelevant after Sprint Planning has ended. 

Thanks Daniel. However, if burndown chart is not expected to be used, how else can the progress towards the sprint goal be tracked? I mean if a team chooses to use burndown chart, the chart needs data and that data will come from the team somewhere before the Sprint cycle ends. So if not daily, how will the data be captured in the chart?

I agree that daily scrum is not a status meeting but isn't reporting burned points towards completion of the increment a form of inspection towards the goal?

If the team pulls items from the Product Backlog that support the Sprint Goal you can monitor progress towards it by seeing Sprint Backlog Items satisfy the Definition of Done.  And if you are actually using the Daily Scrum to discuss the work that has been done, information that has been discovered, and plan the work for the duration until the next Daily Scrum it should be obvious that progress, or lack of, is occurring. 

You are confusing points as being a unit of work but in fact it is a guess at a relative amount of effort based on the information you have at the time the guess was made. To illustrate, have you ever left the house to run an errand and said "I'll be back in an hour" only to find that you only needed 30 minutes?  Or same example but it took you 2 hours? You are estimating an hour but when you start your journey you discover new information that changes the work that needs to be done. 

Progress towards the Sprint Goal can be seen by the number of items that make it across your board to Done vs the number of items that never make it to done.  That is the true indicator of whether work is being finished.  

Since you seem sold that "burned points" are the best measure I ask you to explain how you determine how many points were burned each day?  Since you believe that they represent the actual work, how do you account for a 5 point story that takes 10 days to complete?  Is each day .5 points?  And is that accurate if that story is not actively worked on every day?

Thank you Daniel. I agree to what you are stated and understand the true measure of progress are the done items towards the goal.

Going by that, there should never be the need to use a burn-down chart then, isn't it? So, if a user story is 20 points, we just assess at the end of the Sprint cycle if that story is done or not i.e. always either all 20 points will be done or nothing. I know such charts shouldn't be taken as a measure of team's productivity or efficiency but they do indicate the progress towards achieving the goal (i.e. completing of the estimated stories represented in points estimates). Looks like I missed something in my interpretation of using the burn-down chart. 

Since you seem sold that "burned points" are the best measure I ask you to explain how you determine how many points were burned each day?  Since you believe that they represent the actual work, how do you account for a 5 point story that takes 10 days to complete?  Is each day .5 points?  And is that accurate if that story is not actively worked on every day?

This was exactly my original question. I don't have an answer as to how to determine how many points were burned and hence, I asked for guidance. Without this, the burned points would just be a guess or the teams trying to meet the estimations.

If the Developers were able to estimate how much work was there in the first place, I'd suggest the Developers still ought to be able to collaborate and assess how much now remains.

Would re-estimation of user stories help them to come up with an actionable plan for the next day of work, which takes them closer to their Sprint Goal? If it would -- and they somehow can't do it -- why not?

I guess the recommendation is to not measure task completion on burndown charts but only story completions.

A 20 point story may have 5 tasks needed to complete spanning over a week. So instead of using the task completion to track the progress towards completion in the burn-down chart daily, use only story completion points. The underlying reason: only the story completion is a value-add and not the tasks. While it may not give the correct data on the task progress if the chart has to be updated daily (Only after a week when the 20 story point feature is done, it will show in the chart as completed), this of course makes sense as the feature completion is the true measure of progress. On the flip side, this would mean not much value in tracking the burned points daily as that would mean daily some user story is being completed.

It would be interesting to know if in real world the need to track the burned points daily has never occurred. And it did, how was it managed?....

Hi Mohit,

Focusing on story points is “like a finger pointing away to the moon. Don't concentrate on the finger or you will miss all that heavenly glory.” (Bruce Lee).

Do you deliver story points to your stakeholders/customers or increments of product? Given it is the latter, what are you really “burning” when it comes to points?

In the real world, all sorts of interesting thing occur, and there may be those who do this. This is not something I would do or recommend doing, so I don’t want to contribute to enabling this practice.

There are a number of great recommendations and considerations mentioned above (Ian, Daniel) that are better directions to pursue.