Burn Down Chart : What is the definition of work done in Scrum

Question

I am running a Scrum Project. I am using JIRA as well as TFS as my Agile Work tracking tools.

In JIRA I created an 8-point story. The story was completed on the 8th day in a 10 workday Sprint. Sub-tasks to this story were closed on daily basis which included designing, development, testing, review, UX Review along with other items of the story.

When I check my Sprint Burndown Chart, it showed me that work was actually completed on the 8th day. The problem with this is that work being closed on a daily basis is not shown on the burn down chart and gives an impression that we will not be achieving sprint goal.

In TFS though, the Burndown chart shows the burning down of the remaining effort in Scrum Methodology and similar to JIRA in Agile methodology.

Can someone throw an insight on how work is defined? Is it sub-tasks or is it closure of stories or any other thing?

Answer 1

What is the definition of work done in Scrum

Work that satisfies the Definition of Done, which is defined by the Team.

The problem with this is that work being closed on a daily basis is not shown on the Burndown chart

This is the correct behaviour. From Scrum's perspective, an incomplete story provides zero value, so the burndown shows zero progress.

gives an impression that we will not be achieving sprint goal.

That's not what the burndown is for. The burndown is primarily a tool for tracking velocity, which is only useful for future Sprints. Furthermore, even if your burndown did track worthless effort, it still wouldn't be an appropriate tool for determining your likelihood of meeting your Sprint Goal. Unless your Sprint Goal is 'complete all the stories in the Sprint', which is a pretty poor Goal.

Can someone throw an insight on how work is defined?

It depends what you're using that tracked work for. The Burndown, specifically, is used for tracking velocity, which means it's only concerned with work that meets the Definition of Done.

Answer 2

Work is Done or Not-Done

Scrum does not require the use of user stories, story points, or burn-down charts. They are commonly used as a best practice, but it's important to understand that they aren't framework requirements.

With that said, widely-accepted agile frameworks generally treat work as either done or not-done. Product and Sprint Backlog Items are never "partially done," so they aren't burned down until they have meet the Definition of Done.

Right-Size Your Granularity

If you want deeper visibility into done/not-done, you'll probably need to refactor your Sprint Backlog and burn-down chart to track tasks rather than user stories. If you do that, then you can burn down each task as it's 100% done, giving you a more nuanced trend line.

However, note that "more nuanced" doesn't mean better or more accurate. The additional overhead of decomposing and tracking work to significantly more-granular levels (ideally while keeping INVEST criteria in mind) often exceeds the benefit of doing so. Excessive granularity rarely leads to improved delivery of the user stories or Sprint Goals. In other words, it generally creates the illusion of greater precision without actually making the estimation or delivery processes any more effective.

Furthermore, excessive task-tracking often defeats the self-organizing principles of agile frameworks, leading to more up-front planning and less emergent design. If you over-constrain the solution space through prescriptive upfront design and planning, you take away the collaboration and just-in-time/just-enough flexibility that makes empirical control frameworks like Scrum agile in the first place.

Trend Lines: A Function of Backlog Item Size

Having a trend line that doesn't budge until the very end of a Sprint may be a framework implementation smell, but bumpy or stair-stepping trend lines are usually just a symptom of tracking larger chunks of work. What you want is a predictable cadence, not necessarily a smooth graph. Provided you have a downward trend every couple of days and are meeting your Sprint Goal more often than not, I wouldn't worry about it. It's only a problem if it creates a problem!

On the other hand, if the Scrum Team really needs the additional visibility, then the whole team needs to accept the additional overhead of planning and tracking at a more granular level. Only the Scrum Team can determine whether that's a useful trade-off or not.

Answer 3

The question to ask yourself is:

What information do we want to get from a burndown?

Different teams will use the burndown in different ways.

A popular approach is to burndown on completed stories. This gives an indication to the team if they are 'back-loading' the sprint, i.e. that stories only get done towards the end of the sprint instead of consistently throughout the duration of the sprint. This can indicate problems such as that stories are too big or that testing tends to get shifted towards the end of the sprint.

Other teams like to burndown on effort and so they may use tasks (or sub-tasks using JIRA terminology). This lets the team track the effort they had estimated to complete the tasks against the actual effort they are putting in. It can give an early warning that the team may not complete all the work they expected to do in the sprint.

Answer 4

I've been using TFS for 4 months now, so I'm no expert yet. But I think the burndown provided by TFS (as I understand it) does not work well. You first need to store the availabillity of all team members and the amount of time they will be available for the sprint. Then you also need to register the amount of time left per task.

To me this seems like a lot of work that is not needed. I just created a graph based on a query and created my own burn down on task level. This shows the team enough information about the tasks that are in 'to do', 'in progress' and 'done'.