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.
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.