[valuearb]

Not sure what you mean by point estimates, because point estimates are the only way to accurately gauge the work in a project.

Elaborate work estimations are a fools errand. No one can argue that you can make far more accurate estimates by spending 50% of your time doing research for estimates instead of 2% of your time. But spending 2% of your time on estimates also means you'll finish every project twice as fast.

[taeric]

Point estimate, in this case, is reducing down to a single number. If I'm using the wrong term, please correct me.

Now many people doing this use a "point system" where they escalate the allowed votes as you go up. This is a neat heuristic that accounts for some uncertainty. But it really only boils down the estimates to the easy to estimate tasks. Which are often not worth estimating.

I'm not claiming to be elaborate. But do realize if someone estimates a house project is large, I will have less faith in their estimate compared to someone estimating it will take about 300 square feet of tile, plus for gallons of paint and probably to gallons of mortar.

One shows they have thought and didn't gut shot it. Even better, we have something to actually burn down in the supplies. We can also gauge it with previous jobs to know how long it took to use that much supplies.

Software is tougher, because we don't have the same supplies. But this is why you don't list lines of code, but required screens, technical integrations, and general features. Agreed that you don't want to get too elaborate. But also don't give me some stupid t-shirt sizing or other nonsense.

Not the least of the reasons why, is negotiating a size is dumb. There are literally no reasons not to convince someone they estimated high. However, cutting an integration is a choice that has obvious downsides to account for any speed up in delivery. Even better, it is empowering to choose what you won't deliver, instead of having it chosen for you.

[valuearb]

Ok, then we agree. If you are forced to give an estimate, give a range, and make it a wide range.

When I was referring to "points", I was talking about Agile development. It's planning process is far more accurate than time estimates because it uses points as a measure of the relative work in tasks. It's far easier to accurately say this task is a 3, and this other task is a 5, than to estimate their hours. In Agile planners don't need time estimates because they prioritize tasks based on relative work required (and customer benefit), and the team just works down the priorities until end of it's sprint, and then ships whatever got done.

[taeric]

We marginally agree. I would argue that breaking up between 3, 5, 8, etc. point tasks is a bit of a charade. It isn't that you can compare many tasks of slightly different sizes that is important. Instead, it is knowing all of the tasks necessary.

In particular, those point estimates are not negotiable. Which is why they are less meaningful. Talking someone down from a 5 to a 3 just convinced them to agree they can do a task faster. Presumably at higher risk. Convincing them they don't have to do two of the tasks? That is a clear win, because it is work they don't have to do. Not work they have to try and do faster.

There is also the generative problem of software. As time on a project goes on, changes become slower. So, some task may be a 5 if done now, but a 12 if done later. Similarly, some tasks can piggy back of effort on others, such that they get cheaper in terms of work needed. Though, with time, they probably keep the high time cost.

[valuearb]

Planning poker is not done by negotiating. It's done by doing point estimates simultaneously by the entire engineering team. Providing simultaneous estimates reduces cognitive bias caused by having the lead engineer's estimates influence junior engineers, etc. If they all agree on the point value, no problem. If there is a big difference, then it should open a fruitful discussion so the team can reach consensus. The key is that points don't mean hours, or days or any time measure, it's all a relative measure of the work involved. As long as it is, consensus is usually easy.

All tasks should be pointed in Agile. If anything was left out it's on the team to make sure a story is written for it. For example lets say my PM wants us to estimate 10 stories for the next sprint. If I know I have to do some low level work to update the database to make those 10 stories feasible I'll say we need a story for that, and it needs to be our highest priority since all the other stories are dependent upon it.

But good Agile is done with a Kanban approach, we have a ranked board of tasks, and work on the highest priorities first. If we forgot a task, we add it to the board and point it, and our PMM/PM prioritize it. This can be done at any time in the schedule. When we reach the end of the sprint, we make sure all the completed tasks are done, bug free and we ship.

Then we start a new sprint, working on the remaining tasks, pointing new ones, and working from the top of the Kanban board again.

No one ever need to make a single time estimate, or waste more than a tiny fraction of development time doing any type of estimation.

[taeric]

Apologies for the delayed response.

My main concern here is precisely that it is not negotiated. I like the idea of making sure folks are on the same page. However, the idea of another meeting to discuss what we should instead be building is nauseating.

Instead, meetings that decide what we are not going to build are much more productive feeling. Which is why they should be negotiations. If there is just a list of tasks that has to be done, just keep the list up to date and let the team work on them. If there is concern on priority, make a choice and let the team weigh in. Don't add to their work by asking them to prioritize on behalf of stakeholders.

And kanban is good, but really needs handoff spots between teams. Otherwise, you are just in a constant swarm. Often rewarding the fastest workers. Which is fine, but risks alienating the slower ones that could contribute in other circumstances.

[valuearb]

We seem to argue a lot for people who agree so much.

My viewpoint is let marketing estimate the value of features, my job is to give them a rough estimate of how hard each one is to build, and they can decide priorities based on those two things, and tell me what to work on first. If I go too fast and lesser developers feel left out, I'm happy to pair program and do code reviews with them to help them improve.

Yea, all my projects have to have a defined release process (code freeze, final bug fixing/deferall, final acceptance tests), you can't kanban your way through that, but you can kanban your way to it.