Comment by crazygringo | Hacker News Reader

Comment by crazygringo | Hacker News Reader

Parent Full thread

Here, you might want to read about it:

https://www.atlassian.com/agile/project-management/estimatio...

Points are not intrinstic or objective attributes, like the sky being blue. The scale is arbitrarily chosen by any given team, and relative to past work. But a common reference point is that 1 point is the "smallest" feature worth tracking (sometimes 1/2), and 20 points is usually the largest individual feature a team can deliver in a sprint. So it's common for teams to be delivering something between e.g. 50 and 200 points per sprint. Teams very quickly develop a "feel" for points.

> And then another matter is that points do not correlate to who later takes that work.

Yes, this is by design. Points represent complexity, not time. An experienced senior dev might tend to deliver 30 points per sprint, while a junior dev might usually deliver 10. If a team swaps out some junior devs for senior devs, you will expect the team to deliver more points per sprint.

So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team?

> An experienced senior dev might tend to deliver 30 points per sprint

Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. Isn't complexity directly proportional to uncertainty factors, and therefore inversely proportional to confidence of time to completion?

> So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team?

Basically, yup. It takes a few sprints to start to establish a meaningfully reliable sense of velocity, and the estimation accuracy is why planning poker takes a couple of hours of real discussion over feature complexity, rather than just a few minutes of superficial guesses. But the end result is a far more accurate ability to estimate what a team can reliably deliver in a sprint, and is really good at bringing stakeholders down to earth in terms of what can actually realistically be delivered.

> Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time.

What's ironic? And no, it's not about "someone", it's about the the team. Different people on the team will be able to deliver different numbers of points depending on their skill, experience, etc. This is a major reason for not using time -- it actively recognizes that different people take different amounts of time, that things like sick days and meetings are taken into account, etc.

> Isn't complexity directly proportional to uncertainty factors

Yes, this is an explicit assumption of the Fibonnaci-style points usually used.

> and therefore inversely proportional to confidence of time to completion?

Yes, which is precisely why stories over a certain size are disallowed (the feature must be broken up into parts), and why sprints are measured in a very small number of weeks -- to avoid the accumulation of too much uncertainty.

Reply on news.ycombinator.com