Hacker News Reader

Comment by BirdieNZ | Hacker News Reader

> Pointing is a complete waste of time. I have no idea how long a ticket is going to take until I start working on it. Estimations are usually wrong anyway. If anything, tickets should be pointed once the work is complete to track a teams acutal performance and velocity (output).

It's a complete waste of time for developers, but unfortunately the rest of the company might need to have an idea how long something might take because they need to sell products or services, and get return on investment.

It's really hard to sell people on "we will do these features/this project, but we have no idea how long it will take so just pay us until it's done". It's much easier to work on your estimations until they always get a little over-estimated, and then sell those estimations to the people paying the bills.

View on HN

I disagree. Most tickets my team points (using fibonacci) end up as a 5 or an 8. Sometimes we have something that's a 2 (like a config update or a one liner) but the majority of the time its a 5 or an 8. In fact, we often say if something is above a 13, it needs to be split into more tickets where each would likely be a 5 or an 8.

What would be far better is if in sprint planning, tickets were properly split into blockers and improvements (effectively the same as needs vs wants).

Its up to you and your team to help the PM understand what is likely to be completed in a given sprint between the needs and wants and what will rollover to the next (maybe some of those needs are actually wants, and some of those wants are actually needs - this is part of what sprint planning should involve). Part of that is also the PM communicating what needs to get done (and vice versa). Pointing is just a more arbitrary and lengthy means of having that conversation.

Sprint planning is useful, pointing does nothing. If a blocker ticket is in the current sprint there should be a good faith assumption that it will be taken care of. If something happens putting that deliverable at risk, that's where the line 'people over processes' matters more and you have to communicate what issues are preventing the team from completing the blocker.

I guess I'm trying to say. Pointing as a process is a waste of time and the information it conveys can be conveyed more efficiently with good communication with your PM and team and a decent amount of trust between engineering and external teams.

You say that pointing is a waste of time, but also say that you don’t want something bigger than a 13. If you don’t do the pointing when do you realise the ticket is too big?

The points are purely to get an indicative size of the work, so it is clear work will be done in the next iteration (e.g. 3 weeks).

If other teams within your organisation need to know when an item is likely to be completed then accurate estimation is useful.

I just don’t understand using Fibonacci... seems like they arbitrarily picked a “tech” sequence with a cool name to seem more legit or something. But 1-10 would do just as well in my book, with 10 being roughly the amount of effort and the number of days in the sprint... so the things should add up to 10 for a full sprints work.

Reply on news.ycombinator.com