But velocity of code written is not the same as velocity of value delivered.
In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows.
That's the whole point of agile, to deliver value rather than code.
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.
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.
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.
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).
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...
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.
In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows.
That's the whole point of agile, to deliver value rather than code.