Hacker News Reader

Comment by vlovich123 | Hacker News Reader

Who establishes that sizing? I’ve yet to see anyone who can accurately estimate their own tasks let alone someone who can estimate that for others.

In agile, I think a great time for reflection is between sprints.

Also, I’m super fast but I’ll instead take frequent small breaks in the middle of work (read hacker news, write up documentation etc). There are other times to reflect than between tasks.

View on HN

on this topic, I would like to add this:

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

by Frederick P. Brooks

ISBN 13: 9780201835953

ISBN 10: 0201835959

https://www.biblio.com/9780201835953

I read that twenty years ago, and it is still relevant.

Just curious, do you have any other recommendations that are more or less timeless?

SYSTEMANTICS. THE SYSTEMS BIBLE / How Systems Work and Especially How They Fail

https://archive.org/download/the-unwritten-laws-of-engineeri...

I had a colleague that can be considered brilliant engineer and I believe could be doing all kinds of exciting hard projects and work in the top tier companies. When our manager decided to leave the company, he went along, for a job which in my view is nowhere near his maximum abilities (although he might argue otherwise), quoting the 'Be as particular as you can in the selection of your supervisor.' rule from the above book (which is relevant to the other thread in this topic).

Writing documentation is work, taking small breaks is normal, not cheating.

In the office coffee, smoke, chat breaks were the norm, now people feel the need to justify 5 minutes of YouTube.

You decide as a team.

Concepts like story points and processes like agile sprints are intended to create a more realistic estimate of the work a team can deliver. The process comes with tradeoffs; it won’t work for everyone. So then it’s up to them to bring it up during retrospectives and decide to either change the process or… not.

It’s important to understand that working on a team means that you just don’t get to have all the nice things that you would working individually. You gotta approach it with that mindset.

And you ask the "stakeholders" you are producing for.

If you still want some perfection, ration it out on an easier schedule and use incremental perfection as "treat" for the stakeholders over time while you get something for it at each incremental delivery.

Outsourcing task estimation to the team still doesn't solve the estimates are broken issue. I've not seen estimates get meaningfully better in an environment where the team collaborates on establishing the expected time for a task.

It’s not perfect, and importantly doesn’t claim to be. It’s something in the absence of other ways of estimation. Use whatever works best for your team.

Nit: It’s not “outsourcing” in any meaningful definition of the term to have the team responsible for executing a task come up with estimates.

Reply on news.ycombinator.com