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?

Daily Work Closure - Closing Sub Tasks

Closure of eight pointer story on Eighth day

4 Answers 4


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.

  • Actually, the sprint-burndown is an indicator for how much progress is being made towards completion of the planned stories. However, that indicator only works reliably if the stories are small en numerous enough that the team can close on average one or more stories each day. Commented Jan 15, 2020 at 15:24
  • I have never heard of a sprint burndown being used to track velocity. Commented Jan 15, 2020 at 16:52
  • @BarnabyGolden Really? That's all it actually shows, though, isn't it? The overall chart shows the velocity for the Sprint, and the dots on the chart are a more granular display of velocity.
    – Sarov
    Commented Jan 15, 2020 at 17:20
  • 1
    Ah, I think I get what you mean. You are saying that the velocity determines the starting point for the burndown, i.e. the initial capacity in the sprint. Absolutely and I'm sorry I misunderstood. I thought you were referring to velocity as a metric that changed within the sprint. Commented Jan 15, 2020 at 17:38
  • 1
    @BarnabyGolden No worries.
    – Sarov
    Commented Jan 15, 2020 at 17:42

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.


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.


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'.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.