Burndown chart using % complete remaining instead of story completion

RyanAshline · ‎01-27-2017

I have a seen a couple scrum burn down charts online that have the assignee update the percent to complete for their story. This is then used to calculate and plot the burn down chart.

I know SN triggers on the story state moving to one that sets the story to inactive, but does anyone know or has anyone seen anyone who was able to adjust the burndown chart to calculate on a percentage to complete?

I know it's a long shot thought i'd throw it out there.

Ryan

phsdm · ‎02-02-2017

Many advocates of Kanban, Agile, Scrum, etc. will cringe at this approach. A story is either complete (in production) or not. Can a stakeholder tell the difference between a story that is 99.999% complete, compared to one that is 0% complete? I believe that's why the ServiceNow scrum/agile support doesn't offer this feature.

So you ask, "How do I show incremental progress?" This is where backlog refinement comes in. A story should not be moved from the release backlog to the sprint backlog until the adopter agrees that it can be completed in one sprint.

To stop the sprint backlog from looking like a step function, consider marking stories complete when they have been tested and added to the sprint RFC. That way the easy stuff that gets done on Day 1 will track with the ideal completion line.

View solution in original post

edwardsmith · ‎12-20-2017

Hey, I wanted to chime in on this as we too are trying to make the burndown chart useful as part of our recent adoption of ServiceNow for our agile development process.

I disagree with the answer and how ServiceNow has implemented the burndown chart. The problem is, even if stories are sized such that they can all be completed in one sprint, the burndown chart is useless unless the stories can be completed in a small fraction of one sprint.

For example, if a 2-week sprint has 5 developers and 10 stories each averaging 1 week, then the burndown chart would be completely flat for the first week and then take a big jump down as the first round of stories are completed, and then flat again until the end of the sprint. That is kind of an extreme, but my sprints tend to have a mix of stories where 50% of them take less than 4 days and 50% of them take 5-8 days. The problem is that once the short ones are all done, the burndown chart goes mostly flat while the longer ones are worked.

The solution is, as rashline suggested, to allow for some form of tracking of 'percent complete.' I've done it differently than that in the past, but fundamentally, there should be some way to track partial completion. Not the the purpose of carrying a story over from one sprint to another, but simply to allow the Scrum Master to see if the sprint seems to be on track or not without having to do the 'percent complete' math in their head during every scrum.