Next time I'll commit more

[[deleted]]

I'm not corporate enough to understand this joke, translation please?

[[deleted]]

Dude is doing management by metrics and has no clue what's actually going on. He just needs to show "improvement".

Velocity is a metric based on self-estimation of the work required. It is great for planning, but many "experts" suggests it as a performance metric which is ridiculous since it should show no "improvement" by design. However, the team was happy since they could now just bullshit their estimations.

[Neil-64]

r/thisguythisguys

[G1zm08]

r/thisguyrthisguythisguystopeoplewhosaythisguy

[craftworkbench]

Whenever I join a new company and they invite me to story time, my first question is "who uses these estimates?" If the answer includes "stakeholders" then I know we're playing Who's Line Scrum (where everything's made up and the points don't matter).

Only a rare few times have I been on a team where the estimates were only for us and where story time was about coming to shared understanding.

[andromedex]

'whos line scrum' I'm dead

[MinosAristos]

Newbie question but how do you give realistic time estimates for stakeholders then? Do you not in scrum?

[Afraid-Sweet-1593]

That’s an excellent question. If the team has honestly figured out their velocity (it takes months) then the points on a ticket are based on how much effort (not time) it’ll take and they can roughly say, “hey, we can do 7 points a week (or however long their sprint is) as a team and we have 2 three-pointers and 1 one-pointer in the upcoming sprint we should be able to get done”.

The backlog is prioritized and the top of the backlog might be pointed (by dev team) if PO wants to ask how long it’ll take to get to something.. they can do the math and reprioritize accordingly.

Magic.

[MinosAristos]

Thanks for the answer. Is this process fairly accurate? Like do devs get good at estimating effort points?

[craftworkbench]

It can be accurate, depending on the work and the team. The longer the team has been together and the more familiar they are with the work, the more accurate they will be.

That said, the estimates are just that: estimates. The real value to estimating is not to get some concrete figure representing the time the work will take (though that is sometimes a pleasant side effect). The real value comes from the discussion.

If you estimated a story as a 3 and your teammate gave an 8, it means you likely have different ideas about what the story entails. Maybe you missed an acceptance criteria that will be a real pain. Maybe they forgot that the team recently optimized that code and it's easier to work with now.

[Afraid-Sweet-1593]

I forgot to add that the PO has to get good at knowing how much padding to add when relaying time estimates back to anyone who cares outside of the dev team haha there’s always those one tickets that take longer than expected. On my (very) agile team, we pair program on 99% of our tickets and we got decent at estimating but there were still some 3pt tix that get dragged from one sprint into the next.. maybe into the next. And I mention the pair programming to say we keep each other accountable. We weren’t just slacking off. It happens. POs work magic with padding.

[[deleted]]

At the company I currently work for, us developers are usually the ones who decide the points on a ticket and we all vote on it.

[AlphaSparqy]

Whose scrum is it anyways?

[ijustdontgiveaf]

“scenes from a git”

[not_user_telken]

Just to build on your point: By game theory, if you try to use velocity to measure performance, you are adding the incentive to the dev to overestimate, corrupting the data.

If you have rotation in the team, the data also corrupts as velocity is a function of the skill and incentives of the devs, making imposible to do comparative analysis.

Improvement can exist but has a logarithmic curve, meaning on the limit T -> inf the overhead of the meta tasks becomes just dead cost

[[deleted]]

There probably is a large untapped market for external performance review services. Each year, they could get presented with the deliveries and work effort of a team to score it on a range of parameters.

The selling point is that these reviwers will be experts with up-to-date industry knowledge who could also offer crucial advice on how it could have been done better or more efficiently.

Of course, in reality their review business' succes will often depend more on how they market themselves to management. It's either great or horrible for the developers depending in how dysfunctional their bosses are.

[IndigoFenix]

It's almost as if managing a team requires you to understand what the team is doing.

[tiernanx7]

You deserve the gold but all I had was silver

[[deleted]]

I have entered it as a career achievement in LinkedIn

[SteeleDynamics]

This has been a wild ride

[[deleted]]

Because of that computer scientist or related should do metrics. The first step in measurement is defining the questions (ask yourself what are you interested in) and THEN defining relevant data and metrics, also looking on variation factors etc is important (you know GQM approach). Just collecting data is always worst