Story points aren't supposed to be mapped to time directly.

Spikes and investigations should be timeboxed.

How do you story point spikes and investigations? Just have the same arbitrary story point value for all spikes?

Fuck all those words with a rusty pipe.

1 SP = 1 day

If we start from the premise that "agile" is a lie, then your question is irrelevant.

Before I get hordes with pitchforks at my door, I'll elaborate.

Story points of course do not translate to time. They translate to relative difficulty of a task. The time a story point takes is something that should be calculated statistically from the actual time invested in those story points.

But whose job is that? Managers have the greater picture. Devs know the actual time...

In an ideal world, it's a feedback loop between you both.

In the real world, where "managers" think they (or are *shudder*) your superiors, "agile" is just an excuse for them to still do waterfall but make everything your fault.

Yeah, story points have difficulty and then it's about how much time it takes for your team to develop easy or hard stuff.
Some echos from a class I had. Hope these 2 cents are worth it.

I prefer dem hours tho

You don't. Spikes are used when you don't know how much work something takes. Story points describe the relative difficulty of your work items so you can decide what you should work on to get the best value for your time. It would make zero sense to give story points for a spike, because well maybe it would make sense. Who gives a shit.

@electrineer nerd

@retoor you didn't read till the end, low-attention-span-person

@electrineer I did

@retoor nerd

start every meeting by questioning the definition of "spike"

Let's start at another point.

The lie about doing SCRUM / agile.

Cause if you do SCRUM / agile, then the question would be answered already.

What companies call agile and what agile should be / SCRUM has defined in its manifesto are usually ... two entirely different things.

Like pears and apples.
Like antiprotons and protons.
....

https://scruminc.com/story-points-w...

Followed by the webinar slides:
https://scruminc.com/wp-content/...

Notice something? It all focusses on the point that story points are NOT hours, that they're NOT estimates...

Regarding "spikes and investigations"... that's what the daily is meant for.

Transparency.

Can we achieve the sprint goal or is there any kind of dangers lurking around?

If yes, what and why? Need to reevaluate and rewrite tickets? Need to put it into the next sprint? Etc.

What most companies call agile... is just another perverted Gantt diagram with weird naming.

Nuff said.

What are the story points for a somewhat easy ticket that requires a ton of back-and-forth with DMV employee masquerading around as a security admin to get all the necessary permissions? Because I’ve been done with the code for over a month and I still haven’t been able to test this on sandbox, let alone migrate it to prod and test it there.

Story points: 9
Time in development: 36 days

I just do research before the sprint is estimated at all. Base new non research story points on old data + pseudo code and discussion. Add a buffer of 20%.
Gives me enough leeway to give bean counters a chubby.
For very non trivial stuff like new tech I let them know I’m advance that there may be a delay. If they ask for more I jump ship so I can work with people that have more than 1 brain cell.
Works most of the time.

@usr--2ndry "1 standard deviation or more in the time estimate or difficulty rating"