14

In order to make the burndown chart useful to the Product Owner (or the customer or the user or another stakeholder), then burning down based on stories is going to be the better option. Since a story is supposed to represent something that is useful and meaningful to the stakeholder, so knowing how many have been completed with respect to your definition of ...


12

TL;DR As a Scrum Master, I am unable to predict if the stories are progressing and getting completed as expected. I read that with the burn-down chart the team is burning hours and the tracking will be based on hours and not story points. The burn-down chart is the wrong tool for measuring progress. The correct tools would be: The daily stand-up, which ...


9

Based on previous experience with lots of different approaches, I would agree with your last paragraph - showing anything except true value delivered (tracking tasks, hours, points etc.) often leads to sprints where a lot of items are almost done and very little value is created. You could also look into ways to break the items up into smaller items (not ...


9

Do stories generally get done by the end of the sprint? If so then leave things alone. Tracking the sprint burndown always feels to me like micro-management. The team are responsible for meeting the Definition of Done for stories by the end of each sprint. Track the product burn-up (or burn-down) on a sprint by sprint basis, not on a day by day basis.


9

Theoretically, yes, you could use a burndown chart to estimate when all of the work in the Product Backlog would be completed. However, in practice and as you are seeing, it doesn't always work out. Using a burndown chart to estimate completion relies on a few assumptions, such as that the Product Backlog is well-understood and is generally static. However, ...


8

Assuming due dates are per-item, then no, there's no math that would translate that into a sum of known quantities that could be burned down to zero over the course of a sprint. You could burn down items remaining, and any item that misses its due date doesn't burn down, but this is hard on the team and dangerous to the project. Once an item misses its due ...


7

With more items being added/split and re-estimated with more knowledge seems like your burndown is becoming more accurate rather than not. Issue you are facing is that it looks like it is not burning down but rather up. This is ok as long as the overall trend is down and you are confident that you can complete your work by sprint end. If you are not ...


7

It looks like you should configure Estimation and Tracking for your board. Jira can track progress in either story points or hours: If you select Time Tracking "None" then issues will burn down their Story Points value upon completion. If you select "Remaining Estimate and Time Spent" the Burndown Chart will be based on "Remaining Estimate" and "Time ...


6

What you're seeing is how TFS currently works. I've logged this with the Product Team a couple of times, and I've heard a couple of ways it might be solved in the future, but for now your tasks found and solved on the same day are not reflected. The funny thing is that the burndown will still be correct. Any hours found and resolved on the same day have a ...


6

The answer depends on who your audience is. If it is for the feature crew (i.e. product owner / developers): The main purpose of the burn down chart is to show how the team is trending towards completion of the individual work scoped for the sprint. It also helps the team understand how they are doing with estimations (stories and tasks) and should be ...


6

If we were to display the chart by Remaining Story Points, it would've been a flat line until almost the end of the sprint. This is its own problem. It sounds like you are making insufficient use of swarming. If you work together on and finish Story A before you start Story B, which you finish before you start Story C, then you shouldn't have a problem with ...


6

This question is worth hitting from a few angles: The Direct Answer First, to your question, I've never been in a team that found value in showing days on the burndown chart they weren't working. Feel free to hide those days, it won't hurt anything. As to why Jira puts it in at all, the answer would simply be that some people work irregular weeks. Easier ...


5

"If we were to display the chart by Remaining Story Points, it would've been a flat line until almost the end of the sprint." Not really a problem with story points burn-down. You just have a work in progress problem. Work together on less stories. Your current situation puts you at risk of delivering nothing (multiple incomplete stories == nothing) if ...


5

Why not base the burndown chart on both? It has the benefits to show you some insights about what's happening concerning your tasks (so it clearly shows the actual effort) without putting it out of the context of the stories (as it puts the value on top of it). The most interesting point seems to be that it shows the relationship between effort and value: ...


5

They are genuinely useful, but there are a few factors that can really skew them to be wary of. For those not familiar, when we use a burn-up chart to track work toward some scope marker, like a release, on a project, we can take the average velocity and plot a line forecasting when the total amount of work complete will meet expected scope (when it'll be ...


5

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


5

You need to look at that is happening inside of your sprint. A few things that might provide insight include: How quickly are items moving into your sprint? If everything is moving into progress on day 1 and 2, this may indicate that your team is trying to divide and conquer. In this approach, everything starts on day 1 and ends on the last day by design (...


5

If you already have the three points you mentioned above, you don't need a burndown chart to estimate the completion date of the project. When you divide total story points by the velocity, what you get back is a number of sprints, which are time-boxed (usually) to weeks which you can then layout over a calendar and get the completion date of the project. ...


4

Honestly, I'm not sure I'm seeing the problem. The primary purpose of a Scrum burndown chart is to measure and predict velocity, is it not? In which case, while the chart might not be pretty if most of the tasks are burned down in the last couple days, it's still going to be just as useful. As far as velocity planning in concerned, what happens day-to-day ...


4

TL;DR Changing your method of reporting will not actually address the underlying process issues implied by your original problem statement. Your old reporting process was actually the better one. You should go back to it, but adapt your team's process to optimize for achieving the Sprint Goal rather than for velocity or trend-line reporting. Remaining Time:...


4

Do we need to update original/remaining time estimates when we estimate based on the story points? I'd say no. Filling time information will result in people looking at different metrics. It will defeat the purpose of using story points as an estimate technique. If we estimate based on story points, then we need to look at the burndown chart based on ...


4

TL;DR First of all, never "walk the board" or huddle around a chart for your daily stand-up. The meeting is for dependency coordination, not reporting or trend analysis. Staring at a burn-down doesn't help the team coordinate! Secondly, the goal of a Sprint is to meet the Sprint Goal. If you routinely meet your Sprint Goals with a choppy burn-down, or even ...


4

The first thing to acknowledge is that the ideal line is ideal in the mathematical sense, not in the qualitative sense. In fact, if I ever saw a burndown that matched the ideal line, that would be a massive red flag for me. That said, certain burndown profiles can be indicators of problems and we can look at those. Risk: Work not completing until late in ...


4

Seeing things like "Ready for UAT" and "UAT" in a workflow always raises a concern for me. UAT is almost always outside of the control of the development team, and often even outside the control of the development organization. These activities shouldn't be part of a team's workflow if they are beyond the control of the team. I'd ...


3

The Development Team has completed all the stories that were planned for a particular Sprint. In this case, the team usually decides to speak with the Product Owner to select other stories from the Product Backlog (possibly related to the current Sprint Goal) that can fit within the remaining Sprint time. It is important to underline that, if the ...


3

Never Rebase the Starting Values of a Burn-Down Chart Burn-down measures work remaining in the iteration. For example, if you start a Sprint containing 100 points, complete 50 points worth of work in the first two weeks, and then add 60 points of new work in the third week, you don't rebase the starting value. Instead, you show a rise in the amount of work ...


3

Do we need to update original/remaining time estimates when we estimate based on the story points? In case if you don't use time estimates, why do you need to update these fields? Just don't use them. If we estimate based on story points, then we need to look at the burndown chart based on story points and not remaining time estimates? The same. If you ...


3

TL;DR A story point based burndown chart doesn't measure time remaining. It measures work-effort remaining, and you must use additional metrics to forecast your schedule based on current scope. Story Points, ZenHub, and Burndowns A story point based burndown chart doesn't measure time, it measures work remaining. I won't belabor the fact that canonically ...


3

All graphs of this type are, in my opinion, designed to assist you to plan and prioritize. These are not the kinds of activities that I think should occur during a normal daily standup; these are management activities, not control activities. Having said that, I work with a chart that isn't precisely a burndown chart, but is analogous. My chart has the ...


3

But you are measuring the effective work per sprint just fine. If the team delivers development work but not QA for a few stories, along with some analysis, but nothing else, then the effective work for your team for that sprint is zero. Because nothing of value has been delivered to the customer, and that's the value of a sprint. Not the "story points", ...


Only top voted, non community-wiki answers of a minimum length are eligible