Hacker News Reader

> not all EMs are sufficiently technical to know how long it'll take a _junior_ engineer to take on an otherwise easily-scoped task.

That is a problem if you estimate time as opposed to (intrinsic) complexity of the task.

If you choose to estimate complexity of tasks, then you estimate it without anticipating who would actually execute it and let the routine sprint capacity adjustments calibrate the rest for you.

View on HN

You still need time based planning. You can't go to client and say it will take 500 points to finish the project. You also can't bill story points. Yes, after some time velocity will enable you to easily convert points to time, but in real world when customer is de facto product owner and team size is in constant flux depending on each customer wishes, you need experience engineer to give you ballpark value how long something will take long before the coding even starts.

Software development as an external agency is such a broken concept that I never apply for those jobs.

The interests of both parties have serious misalignment.

Story point style planning makes estimation a team problem rather specific engineers making estimates.

Reply on news.ycombinator.com