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

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.

There are many things about the Scaled Agile Framework(Safe) I don't like, but rebranding sprints to iterations is something that I really like. It's not about being faster, it's just about time-boxing development activities and making planning, communication, demoing and retrospection a routine part of your team activities within that time-box.

Totally agree, the goal is to timebox features and tickets.

If the feature or task takes longer than the allotted time, you get to be agile and reevaluate if you should continue on the feature (does it need just a bit more work) or if its something to come back to in the next cycle.

Just like you say. If something takes longer than expected in the sprint, the retro is the time to call it out, review what happened that made the ticket take longer than expected and share your learnings with the team so everyone is aware of that particular aspect and knows to look out for it next time (maybe it was waiting on another team that blocked you, an unseen complexity, a changing requirement etc).

> We have 3 features we want to develop. Lets aim to complete them in the next 2-3 weeks.

I never actually saw it that way. It's more like we know the velocity of the team is about 25 to 30 points based on past estimations. The team has estimated the following stories and the product owner decides which stories he'd like to see implemented. So he picks a few stories totaling 30 points with the knowledge that it may not get done. And that's supposed to be OK. The more and longer you estimate with the same people, the closer the estimations come to reality. So he has 3 stories totaling 30 points, he definitely wants 2 of them to be finished so he puts them at the top - if the third one doesn't finish then that's too bad but it should be close to done at least.

I've never worked nights just because a PO decided he needed a feature in the sprint. But I'm also the type of developer to say something like alright you want this feature in the sprint that's going on? Sure pick one that's going out or I can assure you it's not going to be finished. I'm not trying to be a dick, but just communicating and managing expectations.

Start calling each sprint "the stroll".

I love this haha, maybe I'll propose it to my team tomrrow

We had weekly sprints one time, the amount of overhead was insane. Even the manifesto says to integrate your working software anywhere from a couple of weeks to months, depending on your situation.

Eh? Integration of software in scrum is the one thing that's really dated these days.

We integrate software every commit.

We had daily builds but they tended to be broken. This is life in many places :)

They did proper integration point releases between teams at various phases, it was more an issue with 1 week sprints to close off tasks resulting in so much overhead that I felt like I was just building momentum and had to stop and gather my thoughts for the retro and planning. We'd essentially lose one work day out of every five.