You are describing this far more charitably than I would. I would describe it as idiocy.

For some (idiotic) reason some management types have this belief that when they measure some metric, it should fit some ideal shape when they put it on a graph, whether or not that makes any sense.

This is exactly the fallacious thinking behind stack ranking where people persistently abuse/misunderstand the whole concept of normal distribution by changing employee evaluation scores to match a normal distribution. It's like these people took a statistics class and only remembered the shapes they saw (and really only one shape) and none of the concepts underpinning those shapes.

Anyone who subscribes to this dangerously simplistic mode of thinking shouldn't have a position of leadership. Unfortunately many times everyone in leadership subscribes to the same cargo cult so they can't hold each other accountable.

Or, in other words, you follow the good old "Scotty engineering estimates" ;)

Shipping valuable features without regressions is my metric of success. Not y=mx+b applied to story points.

Burn down charts are misused far too much to be considered generally valuable.

The way he tells it, no one ever got in trouble for subpar products. But if production numbers were down, someone was going to the gulag.

Apparently, consumers were aware of this and would try to obtain goods that were produced near the start of each month.

On top of the large amount of process and the one week sprints, we also four different dev teams each working on their own microservice app which was tightly coupled to the other apps in the company. Every team had to deploy at the same time, and if one app went down, the other apps went down with it. The company's platform was essentially an ecommerce site that could have been one medium sized monolith, maintained by a single team of 5 or 6 developers, but instead we had 20+ developers, several dev managers, a scrum master, and a large QA automation team. I guess you could call it premature optimization.

There were also plenty of issues on the business side that prevented the company from truly succeeding. The place was a bit of a clusterfuck but it was an excellent learning experience.

In order to pull off this sleight of hand, real work is broken up into elastically-sized multiples of a subjective metric called "points" which the team is allowed to estimate. This estimation game is key as it builds buy-in from the team by appearing to "give them a seat at the table." Chunking the estimations into sprints is a smoke screen to keep the scam going.

Having acquired the buy-in from the people actually doing the work, the estimates are immediately converted to commitments by tracking progress on a burn down chart and telling upper management that the project will begin at 100% work remaining and proceed in a steady, linear assembly line fashion to 0% work remaining after the time allotted.

Deviations from a steady downward slope are interpreted as failures of the development team which paradoxically reinforces the standing of the chart presenter because they are able to "show the numbers". Unchecked, this ultimately elevates them to diety-like cult standing.

As the flawed assumptions underlying the chart are never questioned after the initial implementation, the use of burn down charts ultimately ends with:

- Blue Pill Ending: the company shoots itself in the foot by firing the team for failing to make the burn-down chart linear

- Seller's Market Ending: the team gets wise to the con and leaves the company

- Red Pill Ending: the process manager is fired after heroic intervention by the technical leadership

A process manager that wants to show up with their PMI certification and their burn-down charts faces a precarious end-game.

https://en.wikipedia.org/wiki/Burn_down_chart

Since the shape is always different, there's virtually zero useful information to take away from it.

Some people in this thread claimed that burn down charts are useful for finding out a team's capacity. I disagree - you don't need a chart for this. If your team has a target velocity of 30 points and routinely fails to meet it, reduce the target velocity. Likewise, if the team routinely completes all of their work well before the end of the sprint, slightly increase the target velocity.

My insistence is always that what happens inside the Sprint is the concern of the development team and nobody elses.

However it's important to remember that the team itself should set their velocity in negotiation with the product owner. This shouldn't be set by some external force.

I guess the idea is that points should correlate to time (questionable), and if you're estimating perfectly, that should give you a linear burndown graph. Which is stupid. What might be less stupid is that if you want to get some idea of how well your team is estimating tasks, compared to i.e. this time last year, you could look at the volatility (across several sprints) this year compared to last year, and a lower burndown rate volatility might suggest that the team has improved at estimating the duration of tasks.

However, when you just focus on the volatility as a metric, then people start optimizing for it, which is not the point at all.

Unfortunately, what most organizations actually do is use the progress estimates to try to bludgeon developers into working faster, with entirely predictable bad effects.

It's a line chart that shows story points starting at the top left in the beginning of the sprint. Which shows all points to be done, trending towards 0 points with 0 days left in the sprint, in the lower right.

Linear means that the same points are done each day to allow the line to be perfectly linear between the top left and bottom right.

A pretty common burn down chart would have a somewhat linear slope in the beginning, a somewhat less sharp slope in the middle (mid-sprint slump), and a sharper decline to close out the sprint strong. Notice I said common (more likely to happen) and not ideal, because there truly isn't such a thing as an ideal burn down chart without context. What is ideal to one person/team may be completely different to another.

I personally track my time spent in an IDE slinging code or in app testing using an external tool to help me identify patterns. Purely in terms of time spent in IDE/app, Fridays are my least productive day by about an hour. Mondays are my second least productive. I am at my peak on Wednesdays. Thus I try to shuffle heavy loads to mid-week and the easy, gimme-task for Mon/Fri.

Just like a burn down chart, there isn't some ideal way productive time spent at work should appear on a graph. Well, I guess ideal is 100% of the day in IDE/app , but productivity would plummet. Humans just are not that efficient. Graphing my time gave me insights on how my week/month plays out. Burn down charts should do the same at a team level.

Remember the real goal: money. Sometimes it is money from sales, sometimes it is money saved. (even in case of a charity where there are higher goals money is a proxy for the real goal since it can be applied to the goal in some other way). If management can predict with reasonable accuracy when features will be done they can translate that into how much it will cost. Then they compare cost vs expected rewards (expected rewards is the job of marketing) and decide if they should focus on feature A, B, or both.

Note that many managers fail to understand error bars. There is no way to know exact numbers. However you can predict your likely error, and if the error is too high you can spend more money to reduce the error.

I recommend the book "how to measure anything" for more detail.

In the mean time when management wants perfect linear burn down charts, there is only one way to achieve them: overestimate your stories, finish them early and then go home. If you are paid for a 40 hour week you should average about 15 hours a week, but once in a while you will need to work a 40 hour week (60 hours every 10 years or so). Most management considers this unreasonable (for obvious reasons), but if a perfect linear slope actually is that important to them they will agree.

Even so with regard to work vs. time what determines the time? Launch date?