13

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

TL; DR Low but steady velocity is usually fine. Steadily-declining velocity is a strong indicator of an unidentified process problem, which the Scrum team needs to identify and make clearly visible within the project. Velocity is a Range First of all, velocity is not meant to be either a management target nor a fixed value. It's an estimation tool, and is ...


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


7

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


7

As pointed out by CodeGnome, velocity is always going to be a range. However, if you find that your velocity fluctuates a lot, here are some things to check and suggestions for improvement: Do you account for holidays? For example, if you run 2-week sprints, you may have one sprint with 2 holidays which is 20% less duration than a normal 10-workday sprint....


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

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

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


4

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


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

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

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


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

Draw a line that represents the rolling average over that period, then draw lines that represent upper and lower control limits at 1, 2, and 3 sigma. Then analyze again. Your Y axis goes from zero to 1,000 which can make normal variation look extreme and volatile. You must use control limits to determine if you have a special cause. Else, you have normal, ...


3

TL; DR The Sprint Goal must not be changed during an iteration. Changes that would prevent the Scrum Team from reaching the Sprint Goal must terminate the sprint. The rest is just an accounting exercise that helps the organization understand the cost to the project for scope changes made mid-iteration. When Scope Changes Mid-Sprint Scope changes really ...


3

Strictly speaking, the PO shouldn't be changing stories in the current sprint. For Scrum, best practice would be to abandon the entire sprint and start over with a new sprint planning session, new burndown etc. Other stories currently in progress can still be brought into the new sprint of course. As for timesheets - you should probably ask whoever ...


3

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


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

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


2

CodeGenome, Ashok and David have all given excellent answers. What I would suggest before proceeding with a root cause analysis is to challenge your basic assumption that there is a problem. You say that to you the variability in sprint velocity looks bad, but does this variability have business impacts that warrant the time and effort to investigate the ...


2

The best tool, though you could argue about the free part, for me is a whiteboard or flip chart and a marker. Though any sheet of paper and pen will do. It's easy to implement, too. Just put numbers on your cards, draw the two axes and you're set. Start from there and get your process on order first. Once you and your team have established your own flavor ...


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