Burn-down charts killed scrum #programming

Burn-down charts, velocity tracking, and story point estimation were not originally in scrum. They were added to appease management. A development team benefits in no way from knowing whether they got work done as fast as they planned.

#scrum #agile #burndown #storypoint

[xlerb]

"we're working on different tasks each sprint..." Yup. And all those new tasks have their own challenges. Some you'll know about right away, others you'll find half way into the work, usually after saying something like "wait, what?" or "that's funny...". And then your estimate goes out the window and if you're doing fake agile it's time to fudge the numbers to keep the velocity looking good so you don't get yelled at. Been there, done that, not only bought the tshirt but also the beer mug, the air freshener, and the cat collar.

[manishm]

This really hit home yesterday when my team's PO congratulated us on reducing cycle time by a day. None of the developers cared, and we knew it was due to a bunch of easy tickets. It's only useful as a long term indicator - not something to look at day to day.

[alinmarta]

Well said! May I add, cutting scope may not be a bad thing. Usually from my experience people cut quality, more precisely tests, in order for the velocity numbers to look good

[zwazas]

We tried looking at a burndown chart every morning found that it looked bad even tho work has been done. Realised every time its because of some kind of exception that is not being taken into account after a while you discover there's more exceptions than trends and really you've learned nothing from this chart except that you feel discouraged.

[FoxInTheBasement]

Funny that Agile was inevntes to avoid this "Assembly line" thinking and yet here we are

[donparkison]

Velocity only has one purpose. To help determine the capacity (by taking an average of the last three sprints) to be used in planning the following sprint. THAT IS ALL. This is to help create a sustainable pace that the team can keep up indefinitely.

If you are trying to do anything else based on velocity, like increase it or compare teams or pretend that is in any way a reflection of productivity, you are doing the opposite of creating a sustainable pace by creating undue pressure. You are using the metric for its opposite purpose and creating an unsustainable pace, thus killing your teams mental health and code quality.

Its not the original concept that is bad, it is the bastardization of those concepts, usually by project managers, so they can make themselves look good and justify their existence.

[jprince]

I really like your point about it’s about scrum aims to help you learn that you’re wrong and that the burn down velocity should often be wrong as it means we are learning where our assumptions are incorrect.

[kylehurd]

I needed to hear this for this sprint. Thank you 😂

[pixelboy]

This is not a problem created by scrum but by management

[Bottle-OBill]

Me: Tell that to the Springboks.

Me, a few seconds later: Oh, not that kind of scrum...

[drrodopszin]

Someone said scrum was created to tackle emergencies. That these extreme amount of meetings were there to make sure crucial information is not lost when there's an ongoing incident and everyone's in the loop. As a long term strategy it will not burn down the charts but the brains of engineers.

[Madoc_EU]

The problem occurs once the question arises when stuff will be ready. Or when business has won a bidding with a set deadline and wants to know what other features must be delayed in order to get the time-bound one finished on time.

If developers say "every task is unique, we don't know", that doesn't help. You got to have some way of knowing where development completion stands right now, how much there is left to do, and what obstacles we can already see arising. Only then can business react early and mitigate issues that come up. Also, we need some form of reliability, because otherwise contracts can't be made.

Sure, every task is unique. But you can say something about the needed effort ahead of time, by analyzing the requirements. You can make plans, even for unique tasks. And that's the side of the equation that is controlled by the developers. They can analyze the tasks and give an estimate ahead of time.

Story points and burndown rate / velocity are just a different framing of person day estimations. It's a kind of psychological trick, to take some of the felt pressure of commitment from the developers. "No, you're not estimating person days, you're estimating complexity, which is an abstract value."

At the end of the day, it gets converted into people days anyways. The conversion factor might change over time. And if it doesn't change, developers will often increase their estimates to compensate.

So there is a need to get some grip on the speed with which some features will be developed. Tasks may be unique, but that's not the point where you have to stop and give up on estimations altogether.

[nope]

I agree in spirit, but have to offer an important upgrade to this. Velocity should ONLY benefit the TEAM that is curious about empirically looking at whether or not their continuous improvement efforts are affecting their outcomes. (You are inspecting and adapting, right?) Important nuance there. Empirical measurement can actually be a superpower for a curious, mature, confident, self-organizing, psychologically-safe team.

It’s never meant to be a proxy for “work done” or “value delivered”. And it’s certainly NEVER meant to be wielded by ham-fisted micromanagers fixated on vanity metrics vs. actually learning and delivering client value sooner and more sustainably than the competition can.

[blipojones]

Every dev just needs to keep saying "ok whatever you say, btw all this is horseshit and burning time" to their non-dev superiors. Sympathise their boss and bosses boss is also a non-dev or never had been...

[_Mentat]

Why do you even want to know your velocity? Anything not done this sprint will be carried to the next. The review may change everything anyway.

[aperson]

If your scrum velocity is too low in a start you are burning though cash and then your business is done. How is insulating them from reality helpful?

[wheresjesse]

The purpose of scrum is to create quotes for the cost of a given products development… I think you missed the point.

[geteducatedyoufool]

I always felt stupid over not being able to understand why this/storypoints were important in my different teams

[gokukakarot]

You have to understand, you are comparing coding with software engineering.
Software engineering is like any other corporate job. You start off at the bottom.of the Industry, as a labourer, a keyboard striker and then you move up the corporate ladder. And most corporates are like this.
It's just a fact of life. If you want to write code all day, the industry recommends to join your basement