The differences I've observed between successful-and-unsuccessful, Scrum-and-Kanban have been dominated by people over process (yes, I know).

1. Does the team have the right people, with the right skill sets, wearing the right hats? (e.g. BAs or PMs doing those actual jobs)

2. Does the team have self-motivated, high-performance people?

I have yet to see any process that can overcome "No and no."

Large tech org's knee-jerk response to failures is to increase the formalism of their agile frameworks, but that's just a bandaid over gangrene.

If they think the solution to bad people is more process, they've already lost.

Barry Boehm sort of summarised this fairly well in Balancing Agile and Discipline, although I'm sure he would disagree with my characterisation of it:

- If you have unpredictably changing requirements, and a small-ish non-life-critical product to build, and a large fraction of good people on the team, you should use an agile process.

- If you have unchanging or predictably changing requirements, and a large fraction of not-so good people on the team, you should use a plan-driven process.

But what if you have unpredictably changing requirements and a large fraction of not-so good people on the team? No process can save you now.

Yeah, but scrum can overcome yes-yes by taking a bunch of skilled and motivated people and forcing them into an ineffective process. That is exactly what happened in my last team.

So those skilled and motivated people are estimating piecemeal tickets, too micromanaged to be able to fix actual issues they clearly see around them. It is forced helplessness You can't overcome bad process and scrum is a bad process.

Scrum advocates always end up blaming the people on team. Even if that exact same team was performant and scrum literally killed 70% of what was good in it.

But people are a ceiling, not a floor.

Of course process can't make bad programmers good.

But good process can dramatically improve the value delivered by a team of good programmers. People don't spontaneously self-organize in optimal patterns of internal communication and accountability and external communication, no matter how self-motivated and high-performance they are.

To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.

Isn't that because the product manager is gathering requirements from other orgs/users?

> I have never seen feedback from estimation to requirements.

Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.

Yea, they tell you that they don't believe your estimates and stop asking for them before setting the deadline.

Then that's not agile.

The entire point of agile is that a PM can't do that. Large estimates force a PM to go back to stakeholders and revise the desired features to something that engineers have consensus that should be deliverable within the next sprint given their historical velocity.

If you're not doing that, then you're not even in any conversation about agile/scrum.

I'm almost afraid to ask but what unit of time does that "8 or 13" correspond to?

nah it's all good. it's just the "estimation value" which is technically arbitrary, but a common practice is in a 2-week sprint, 1x eng 1x sprint is ~5 points.

By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is then it'll take 2 sprints.

Anything 13 or greater is saying this ticket is so big we can't even begin to accurately estimate it - PM take it away from us! It's fun to see 21 or 34 pts... it's all a joke at that point.

Is that common? I thought it varied depending on the team, but usually that 1 pt is the shortest meaningful piece of work. Where I work now, 5 pt is not especially much. We have total story points delivered in a sprint around 120.

As mentioned, it's technically arbitrary, so you just need to get used to how your org does it. There's no right or wrong as long as your org agrees on the value of those points... sort of like bitcoin, ha ha (cries in BTC).

You didn't say how long a sprint is nor how large your team is, which makes me suspect that you don't handle measurements well in general.

Thanks. My teams have always estimated in hours (though at times these hours were called points) so I was a bit frightened to hear that an estimation of 13 hours would be considered bad! I guess if 13 means 26 person-days I get why people would be nervous – even I would suggest breaking it down into smaller pieces, if possible!

The main point of points is that they are not supposed to be equivalent to x amount of time.

They're supposed to represent a measure of complexity.

How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on.

They're then used to see how many issues will fit in a sprint, which is a measure of time. So everybody ends up treating them as representing time anyway...

That’s the theory but it doesn’t help managers so they still convert it back to time somehow.

Scrum was never for managers. If a manager is involved in predictions, it's not scrum. Scrum is about delivering the best you can each month, with client/management setting priorities and then appreciating what they get, instead of trying to steer the car from the boot.

Sure, I get what scrum is. "Scrum" in the real world isn't that though - at least 80% of the common case (check the other comments).

Theoretically it's arbitrary numbers. Then a factor specifically calculated for your team gets applied to it to turn it into hours or days.

But in reality it's ideal hours or ideal days.

The 8 and 13 come from the fibonacci sequence.

You can still do estimations and clarification discussion as needed without making it a meeting where it has to happen in one formalized batch via point systems.

The meeting-centric focus of dogmatic Scrum team rhythms that attempt to create standardized estimation sizes in order to produce velocity metrics is obscenely slow and a largely a waste of time.

Measuring output metrics at all is worthless. Measuring the impact of delivering working code is all that matters.

Why do you need an explicit meeting for that? Just talk to each other as you uncover new information.