Me: *gives 8 story points*
PO: Why is it 8 points? this is just copy-pasting and should not take more than 2 hours.

Do it yourself then

Every fucking time.

But here is the secret: Story points are for statistics only. They are totally irrelevant for your part of the job. Don't argue over them. Let em have their will over their part of the job. It is their statistics that become less useful for controlling and planning - not your code.

@Oktokolo sad but true

@Oktokolo that's why they should listen to you. So their statistic for planning and controlling is worth something. On the other side you should be able to justify the 8 SP.

It's a team effort

Let me share a story then:

Some years ago I asked a “blacksmith” to make a simple yet useful gate for me.

At the time he said: of course, xxxx is my price to make a gate for ya.

I replied: wait, that’s too much for a simple gate!

And then he answered: do you know how to make a gate ?

And I said: no…

After that, he said: so… how can you set the price if you don’t know to do it? Do you even know much the materials cost?

Think on that. Same shit, different profession.

@Oktokolo Yeah but those statistics are then also used to assess the developers' performance.

@gcavalcante8808 That just shows how much money someone is willing to pay for the time.

It could be possible to just learn how to make a gate by yourself, learn blacksmith. But is all that time worth the money someone who did all that asks ?

Exactly @Grumm!

On the other side, if you estimate using a median or average between the devs you can get an ideia on how familiar a dev is with a tech or software component.

What you can’t do in my opinion is to set a hard “price”/estimation for someone’s work without even know what kind of task or job it is.

“Nothing is easy”.

If you are pasting the same code then you need a refactor, which is a different and interesting thing to do.

@KDSBest The justification is easy: My gut tells me, it is an 8 SP task. I can't predict the future. I can assess the task at hand roughly by using a lot of gut feeling and some reasoning because normally the task isn't about replicating stuff i already made.

And exactly that is, what the original idea of story points is meant to be: Rough gut feelings of the devs. The "higher ups" can record how much time how much points did cost in the past and hope that the average is roughly constant over longer time periods spanning months or years. And Scrum evangelists say, it typically is. But it probably isn't, when these gut feelings aren't actually comming from the devs.

And if you want to know how reliable story points are when looking at non-neurotypical devs, ask @kiki - she can likely tell you.

@Oktokolo thanks
@immutable for my neurotypical colleagues, I mostly use three-point estimation, I found it to be quite accurate. For myself, well, it’s a different story. I do things backwards — you tell me the due date you want, and I’ll cut the scope accordingly. It will work and solve the problem! Just not in the way you expected.

@gcavalcante8808 this is called haggling. And you say no I don't know how to make a gate but the other guy knows and does it for half the price. Why are you worth double?

Blacksmith: guess what can explain the price like I use steel instead of wood or I'm more precise whatever

@Oktokolo if you have to put in 90% guts and 10% knowledge it is actually simple. The story isn't ready for estimation. Maybe a timeboxed or something investigation story makes sense.

@KDSBest That's the thing with software development. Most stories contain surprises, research or debugging. Combined with an iterative coding style, predictability is rather low. And i don't actually know how much gut feeling is in my predictions - but it's a lot.

I also are a special case too because while i am sortof neurotypic, i aint thyroid typical - so what i can do fast today i might only can do slower tomorrow. And there are a lot of people with physical or mental malfunctions (probably overrepresented in software development because it attracts people who like computers, abstractions and logic).

There are enough unknown factors to make me believe that it is a bad idea to assume good predictability of dev output. Maybe that changes with advanced AI in the future when workers aren't just treated like machines but actually are machines...

@Oktokolo I do alot of new tech stuff for my clients, which always has suprises and such. There is always a way to adjust the story points in that case.
Just because last week this was a 3 doesn't mean it is never changable. If a new discovery changes it to an 8 the SP should reflect that.

@KDSBest Sure. Also new tasks and tickets can be persisted in the tracker as they are discovered. My point was more that there are a lot of devs (me included) which's output isn't that planable. There may be lack of experience in general or for the task at hand. Some have physical or mental anomalies. The research parts of dev work add another uncertaincy on top.

In the end, story point completion times of the past may or may not be useful for projecting completion times in the future for a specific feature, dev or team. Whoever does that, has to be very careful to not rely on them too much as the error margins of projections can be absurdly humonguous. So the projections if used have to be updated regularly and decisions made on them have to be updated too.

All in all, i am a pure dev. I don't do management or controlling. And while i am happy to help whoever does it to do their job, i don't fight with them over story points as for me, they have no value.

@Oktokolo I mostly agree. The SP mapping to Time makes never sense tbh.

@lorentz The performance review factor. Hah. This is why i have said to teammates to estimate high and deliver at that point. We can do x amount of points in a sprint. The business agrees to the amount of points in the sprint. So we deliver predictably and everyone on the team has their own point speed. Never change scope unless someone needs a few one pointer tickets to round out their stats.

Then at performance review time we see consistent achievement and ongoing improvement with the technology.

@Oktokolo great insight and wisdom