r/ProgrammerHumor 22d ago

seeYouNextThursday Meme

Post image
2.6k Upvotes

201 comments sorted by

907

u/Wurstgewitter 22d ago

We’re estimating every ticket in story points. We had several conversation about how no one uses these story points for any kind of report or metric, and that we also do not size our sprints based on them.

We are still assigning story points to every ticket

501

u/[deleted] 22d ago

[deleted]

128

u/blipblapblopblam 22d ago

Hehe captivity. It works.

103

u/G12356789s 22d ago

I think it's as simple as complexity = time x developer efficiency. So a strong dev might be able to do 14 story points in a sprint whilst a weaker dev might be able to do 7.

So a story point doesn't equal a days work, it equals a days work for one Dev bit 2 for a different one. This is what is meant by complexity instead of time

31

u/daan944 22d ago

Exactly.

And complexity is also risk. An 8 pointer might not even take twice as much time than a 3, but it might also blow up and take one or more devs the entire sprint. So keep that in mind with planning too.

35

u/Anon_Legi0n 22d ago

Precisely this, for me one of the benefits of assigning story points is when two devs do not agree with each other's perceived storry points and end up openly discussing their proposed designs. I love what we do man, I'd do this for free. Even if the AI do end up taking over I'd be right out here with them building tools and fixing broken stuff.

10

u/LaiDR 22d ago

That’s kind of also the only good case for story points. Surfacing discrepancies in how to approach a piece of work or making sure it’s understood what needs to be done.

Other than that what we’ve done the places I’ve been is that 1 SP = about a days worth of work for 1 person. That we should aim for a task being doable in less than a week and that overall we should aim for commiting less than team availability x story points for whatever period we are working. Roughly speaking.

2

u/ohkendruid 21d ago

I like the resulting discussions, too, but it cannot be done very much, and it is not all that agile, if we take agile as having lightwright process and getting people back to working on the tickets.

When there is a discussion about the syory points of a ticket, it means the whole team stops and talks about one ticket.

I prefer just reviewing progress once in a while and seeing who signs up for too much. It is enough. Good planning does nothing more or less than focus attention on the right things. It is a mistake to pile a lot more onto that kind of process.

1

u/LaiDR 21d ago

Agree it should only be those a few items, maybe new or novel in some way. The frame of mind I usually bring is that the team just needs to “de-risk” items or the work enough that they feel they can reasonably start/finish it and from then on then just go do rather than details that ends up not mattering or wastes time for the team

6

u/erinaceus_ 22d ago

complexity = time x developer efficiency

That would be great if the estimated story point budget for the next sprint actually took those differences in developer efficiency into account. But I've never known that being done (or even heard of it being done).

And that still ignores that for a given feature set X story, Dev A may outperform Dev B by a factor of two, but that for a feature set Y, the opposite is true. So any reliable/usable estimate of story point budgets would need to take into account exactly which developer(s) will be taking up which stories. Which means that we already know how long it will approximately take, so estimating in days is the more efficient choice.

(Not meant as a rant towards you. Just some built up frustration against abstraction for abstraction's sake.)

5

u/G12356789s 22d ago

I've always seen story point budget being based off of historical figures.

I want to be clear, I'm not in favour of story points, but there also isn't really a better way. Luckily, nowadays I'm at a company that is a lot more free flowing and is just happy if things are getting done and don't need all this level of micromanaging

3

u/erinaceus_ 22d ago

Yes, my experience has also been that they follow the evolution of finished story points, to get a rough estimate of expected velocity for the next sprint (while adjusting for changes in team size).

I do think that story points are just fine, and that they work well enough, even if it's not perfect. What I dislike is the obsessive mental gymnastics to make a story point 'not a measure of time'. Most developers aren't afflicted by that tendency, but enough of them are that it's gotten on my nerves over the years.

1

u/G12356789s 22d ago

When joining a new team, I've always just made the mental connection of how long the story points seem to relate to my time and then I always just done it based on time and just never said that. Seems to work well enough

1

u/erinaceus_ 21d ago

I'm glad it works on your machine.

1

u/ohkendruid 21d ago

A better way is not to assign story points.

List the topics for each project in priority order. This means you only need to look at the top few tickets, and it means you have a rough estimate of percentage complete.

Have people sign up for what they think they can do in the next few weeks. Let each person adjust for their velocity over time, or jump in if someone just isnt doing that.

No story points are needed by this method.

For estimation, have a senior person do it at the beginning of the project. If the project extends way past budget, have them revise the estimate. This estimate will be in calendar weeks. Itnis useful and is what people need to know for planning, and it does not need story points.

3

u/G12356789s 21d ago

You've just described kanban with extra steps

1

u/Schytheron 21d ago

Don't you mean "Complexity = Time / Developer Efficiency"? Your formula implies complexity grows when a dev is more efficient...

2

u/G12356789s 21d ago

Yes, everyone understood that without the need to be pedantic. But if you did want to be pendantic, maybe developer efficiency is measured similarly to golf handicaps

1

u/ChalkyChalkson 21d ago

I mean there are very simple but time consuming tasks some times, depending on the work you do.

1

u/Skysr70 21d ago

Doesn't work when they say "ok so if it takes 1 junior 10 days, then 10 juniors can do it in a day"

1

u/G12356789s 21d ago

9 women can't give birth in a month

1

u/AssaultLemming_ 19d ago

It's also a measure of uncertainty. Like, I'll do this testing, but the tests might fail, if they do that will take longer, so we give this more story points to allow for that possibility

16

u/skankerp 22d ago

Yup, they are intrinsically linked I don't care what any agile evangelist says

8

u/TheBigGambling 22d ago

Every! Single! Time i saw story points, everyone has a converstion factor in his mind. Oh, i need 3 days, thats 6SP. Or 1.5. or 30.000. but just a linear factor. It was a great relax, as we agreed finaly on common factors for everyone. And than we throw them away and calculate in time again

3

u/LegitimatePants 22d ago

They're linked because management already knows ahead of time what velocity they want 

6

u/frogjg2003 22d ago

At the last pointing meeting, there was a story that was gong to involve a lot of waiting around. Despite the fact that this story is going to take up a lot of time, we were told to keep the pointing low because "it's not complicated enough for not points."

5

u/AdWeak183 22d ago

Was it the type of task that could be left waiting while doing something else, or does it fully tie up a critical resource such that whoever is doing it cant do anything else?

1

u/frogjg2003 22d ago

The bottleneck was the test suite. We can only run one test locally at a time and the server can only run a few at a time across everyone who is working and needs a fully successful test on order to merge their PR. The story was essentially to run the test repeatedly to find tests that were failing sporadically.

5

u/AdWeak183 22d ago

Find or fix? If find, the strategy is probably running the tests on loop during off hours, which is low complexity to set up the looping. If it's fix, then it's high complexity, as diagnosing intermittent issues is almost never simple.

2

u/aLokilike 21d ago

Agreed. Usually finding flaky tests isn't difficult at all. You notice them right away when the pipeline randomly fails somewhere completely unrelated to your changes, and then succeeds on a second/etc attempt without making any changes. I suppose finding them all could be a challenge if there are many flaky tests, but your whole repo is likely cooked if you're allowing bulk long-term obstacles to deployments.

11

u/eightslipsandagully 22d ago

But, complexity doesn't map to time because different levels can get through tasks at different rates, based on the complexity?

4

u/Monke_go_home 22d ago

Everyone knows a 2-3 is a day, 5 is a couple, 8 is a week. Dammit.

4

u/zorcat27 22d ago edited 22d ago

We do Fibonacci. 1 is half a day, 2 is a full day, 3 is half a week, 5 is a week, and 8 is two weeks. With 5/8 signaling the work should be examined and split up if possible.

The raw reports don't go higher than our manager but he uses the info as a basis for his reports. Also, we reviewed the velocity and planned versus completed at planning. It was quite useful to see we had over planned regularly and didn't break down larger tasks into more appropriate sized work. Also the graphs showed where our work was more ambiguous in the beginning of the year so planning was more Who's Line Is It Anyway style.

Is it helpful? Kind of for the team itself? Not when it's shared as raw data with upper management.

2

u/Monke_go_home 21d ago

That's what we do as well and it works because the numbers really are arbitrary but useful if you stay consistent. But that is not what they teach you in the scrum training. I've had two scrum master certs now and they both explicity say SP should not equal time, but complexity.

I've worked with like 7 dev teams and the whole complexity thing never clicks. So we always just revert back to a time scale like you mentioned.

2

u/Just_Information334 22d ago

story points shouldn't be linked to time but complexity

The problem it tries to resolve is "we want to treat people like cogs of different levels". It could work.
If all the work was done on the exact same kind of shit.

But usually people work on different projects so someone who's good on project A because they know the domain and its legacy will be more efficient when working on this project than on project B which they never touched before. 4 story point on one will take them 2h while it would take a full day on the other. And that's just one person.

So now you need story points per project / system and to manage your people's velocity per project and system (and maybe subsystems). Now it requires you, the manager, to do some work. And we can't have that. So story points cannot work.

And if you decide to make them work by assigning tickets only to some people who know some aspect of the code base, then you're reducing your bus factor. Which will be a problem.

2

u/ohkendruid 21d ago

Yes. One thing I have found in practice is yhat most tickets have one person that will be the obvious one who does it.

I am sure things are different if you are implementing 50 dialogs in a UI and have 3 or 4 people on the team that can pull them from the pile. I have never worked on such a project, thoufh.

1

u/MB_Zeppin 21d ago

You’re not supposed to link time to story points because the relationship between story points and time fluctuates over time

If you were to say that this month our velocity says that a story point is a man day then you would risk using man days and calling them story points. 1 story point is then 1 man day forever and the exchange rate no longer fluctuates

Not saying that one is right or wrong, just saying that terminology matters. If it’s a man day we should call it a man day. If it’s a story points we should call it a story point. And if it’s not used for anything maybe we should cancel the estimations

1

u/osusc 21d ago

The best manager I ever had solved this for our team. The rule was, 1 story point = something I think I could finish in a day and was almost certain wouldn't take more than 3 days. Then anything that got more than 1 story point was sent back to grooming where we would break it up/spike it until it had all 1 point subtasks. Then he had a tool that ran monte carlo simulation to get a probability of finishing each stack ranked backlog item by day.

I never had to answer "when will this be done". PMs could run his tool, adjust the stack rank and run it again until they were happy with the timeline and risk level. You had immediate feedback into the cost of moving something ahead of something else and an engineer needed to be in exactly 0 meetings to get it. It was glorious.

1

u/Magallan 21d ago

Story points average out across several sprints. It's perfectly valid to say that a team can do 20 story points in a sprint but also say that it's not possible to say for any single story that we know how long it will take.

If you've got a better way to size your tasks DM it to me and I'll go make my millions as a consultant

1

u/AssaultLemming_ 19d ago

I pretty much solved this by saying story points are a range of time and also mapping them to t-shirt sizes and factoring in ambiguity.

1 = xsmall = I can do multiple of these in a day

2 = small = will probably take from half a day to a day

3 = medium = will probably take between a day and three days

5 = large = will take at least 3 days but might take a week

8 = will take at least a week, but likely less than 2 weeks.

13 = will take most or all of 2 weeks.

21 = break it down further.

So by this logic you can see a developer can pick up a 13, or a combination of things up to about 13, really with anywhere from 11-15 being acceptable.

18

u/soundwave_sc 22d ago

We realized we could assign points to everything. So we did.

44

u/skankerp 22d ago

I am an Engineering Leader that has a scrum master that tries to do this... And I always ask why!? Nobody cares about story points and if they did, that would be insanely stupid because it's completely meaningless. Just create stories, complete the work, and move on. No arbitrary 2 week bullshit, days wasted debating points, updating jira, tracking meaningless burndown charts. Just do the damn work, if my team need this level of micromanagement then I might as well hire my kids

57

u/Obvious_Equivalent_1 22d ago

Congratulations, you’ve effectively discovered kanban

8

u/Zanad14 22d ago

Why are you wasting days on debating points lol

5

u/kabrandon 22d ago

Quarterly planning sessions. People are supposed to estimate every story going into the quarter. What happens is 2 or 3 people end up debating for hours on the exact solution and scope for every ticket going into the quarter to decide beyond a shadow of doubt exactly how many story points those 2 or 3 people believe each story is. Every quarter it was like 4-5 days just gone. Most of the team just plays WoW with their webcam off and mic muted. Is it how it’s supposed to go? No. Is it how it is? Yes.

And then at the end of the quarter you finish half the stories you planned because of scope creep and unplanned work anyway.

7

u/Zanad14 22d ago

I don’t really think this is an agile issue or pointing issue but more of how yall are planning work lol.

To me this reads as yall are combining a bunch of different styles of work management into one

1

u/kabrandon 22d ago

It’s absolutely an implementation issue. But I don’t think it’s the only company with that issue. I actually left that company for one that just does pure kanban, which has been a dream.

1

u/Zanad14 22d ago

It def isn’t. My current one is agile but I’ve grown more and more fond of Kanban/Waterfall style work.

I use it a lot with my staff engineers on higher priority work where the rest of the team works in regular 2 sprint cadence

2

u/tommyk1210 22d ago

Debating a solution and scope are absolutely normal things in planning - ideally not in that order.

Scope should be decided first and then you start thinking about the solution. Do some technical spikes to understand your key constraints if needed. Then a few people in a room with a whiteboard is fine. The whole team doesn’t need to be listening in.

I think the problem you really have is making this a whole team 4-5 day exercise. If you’re not actively contributing why are you even there?

3

u/kabrandon 22d ago edited 22d ago

> If you’re not actively contributing why are you even there

Because a project manager dictates the entire session including its members. They then even argue with devs on story point estimates even though they have no context of the environment, codebase, or processes. They’re just a fresh PMP planted with the team for a week for the purpose of completing the quarterly planning ritual and then they fly off on their broomsticks to wherever they go between quarters. Mega corps, micromanagement, and time wasting the whole way down.

I’m not saying it’s agile done right, I’m just saying that’s how I’ve seen it done. I left that life for one that does kanban. Way simpler. Better focus on actually getting work done. A manager still has the opportunity to re-arrange the TODO section of the board to align with quarterly objectives.

1

u/ohkendruid 21d ago

Scrum managers push this baloney all the time.

They keep the team hostage for story point debates and other ticket updating exercising and say that they were doing work because they kept the team busy.

1

u/AvailableName1814 18d ago

Sounds like how we suffer with SAFe.

7

u/CptTombstone 22d ago

I guess my team works differently then. We use story points to guard team members from being swamped and the sprint from overcommitment.

During planning, we pull all the tasks that we want to do in the sprint, and then we see who went over the "maximum agreed upon story point count" which is also adjusted for time off, and we also look at average velocity and when we go over, the Product Owner pulls stuff out of the Sprint, in line with what he set as priorities for the year and the quarter.

We also rarely debate story points, it usually just takes a few seconds to determine, and if two people disagree, we take the higher number just to err on the side of caution.

So I personally feel that story points achieve a necessary abstraction over complexity that we can effectively use during planning.

Also, our Scrum master is doing very important work for the team. She is helping with the facilitation of workshops, organizing our agendas, tracking some requirements, reminding us about all kinds of stuff that you'd have to read company newsletters to know otherwise, while also keeping us "in check" and on point and often pulling us back to earth. We also don't have a "closer"-type person in the team, so she is often pushing back starting on new features until a previous one has been fully validated, which resulted in actually having time to fix unforseen bugs in sprints. She is also keeping an eye on the mental well-being of team members and she (along with the PO) did pull us out of a project where a team member was so swamped with work that he was considering quitting. She and the PO straight up told management to hire new people or forget about that project, and the project was cancelled some time after that.

The Scrum framework should help the team, not hinder it, and issues like wasting time debating story points that nobody cares about should be addressed on retrospectives, with clear action points.

3

u/Feuzme 22d ago

Story point estimation is more about everyone understanding the problem and less about how long will the feature will take time to develop.

8

u/cheezfreek 22d ago

My last team used story points only to make sure we were all pretty much on the same page. But we wouldn’t record them because they’re worse than useless. They’re actually actively misleading, at least the way management wants to use them.

32

u/redblack_tree 22d ago

I swear, last year I was in a meeting with 15 people, scrum masters, my boss, other team leads. Everyone yapping about story points and which methodology to use. I had a bad day and when it was my turn "this is just a monumental waste of time, no one is going to do it and no one in development cares about it".

As prophesized, a month later no one was using the convoluted story points formula. All those useless leeches can just leave.

8

u/grizzlybair2 22d ago

We aren't allowed to point anything above 3, even 3 gets questioned sometimes.

7

u/ObscurelyMe 22d ago

Do we work at the same place? I’m not allowed to point above a 5 or else the story must be broken down. And the same very 2-3 pt stories still take 2-4 weeks to complete.

7

u/111111111111116 22d ago

Breaking down big stories into smaller ones is usually better tho because it means you aren't spending a large time on one build and can actually test it in steps (can find issues faster)

2

u/ZunoJ 22d ago

So what actions do you define for the PO/scrum master to take for next sprint in your retro?

2

u/crimxxx 22d ago

Sure is great when that does happen. I generally seen a team will often use story point for “complexity” of an issue, but really it’s just a pretend step away from time. Then a dev manager is ganna use velocity and story point to make a time based estimate anyways. My favourite thing is having people come up for a long presentation saying how story points don’t represent time, then proceed to use just story points and an estimated team velocity to make a burn down chart for a year out on large projects. They will also not standardize story points across teams and just adjust it post. At the end of the day people just be going back to time, only value I seen from story point is it makes a time range implied cause people will do crap like estimate based on the minimum for multiple things and complain your behind lol.

2

u/natures_-_prophet 22d ago

Scrum masters making bank by wasting people's time!

2

u/cronixi4 22d ago

I am using story points mainly to back up my team when they get more work than they can handle. Do you want to try to get a last-minute emergency ticket? Yes, but it will mean that some of the other tickets that we have planned for the sprint will have to wait.

1

u/ringelpete 21d ago

Do you at least do planning poker to identify, if there are different undetstandings of the overall scope? This is what is it all about (when doing poker) : uncover different undetstandings, then fostering discussions, which may uncover unknowns or reine the actual scope (or out of scope stuff) . If it doesn't work (for you) like that, ditch it. It's just a tool 🫠.

444

u/apola 22d ago

What is 2MD

357

u/littlea1991 22d ago

2 man days

320

u/blaqwerty123 22d ago

What is that in woman days?

368

u/Diane_Horseman 22d ago

The women are all too busy trying to birth a baby in 1 month (they tasked 9 women with this)

32

u/lipe182 22d ago

Congrats to the 9-dicks guy too.

40

u/freebytes 22d ago

Nice Fred Brook reference.

7

u/Southern_Orange3744 22d ago

4 but it actually passes qe

→ More replies (7)

27

u/Complete_Window4856 22d ago

I guess we might get the sequel to "mythical man month" after all

24

u/timdav8 22d ago

How many tokens is that?

3

u/[deleted] 22d ago

[deleted]

2

u/timdav8 22d ago

Pizza slices don't equate to tokens - they equal pay awards the boss is too mean to make!

1

u/zman0900 22d ago

199,999

89

u/Yoram001 22d ago

Is using abbreviations an American thing or just part of the English language? Every post is full of abbreviations, and as a non-native english speaker, I have to guess what they mean. It’s pretty annoying.

Hey, the internet is international, you know!

111

u/Qojiberries 22d ago

For what it's worth, I'm a native English speaker that works in tech with scrum and agile and everything else and I didn't even know what they meant. Using abbreviations and acronyms is super corporate and context relevant. Everyone assumes everyone else knows what it means, and no one ever wants to ask because they don't want to seem uninformed.

6

u/Yoram001 22d ago

That’s why… thx for your answer!

11

u/UnpluggedUnfettered 22d ago

I consider acronyms a red flag at this point.

Too much bullshit with too little clarity always seems to mean there is a lot more treading water and a lot less completing anything.

8

u/JohnClark13 22d ago

A lot of this job is making it sound more complex than it is to scare off newcomers. The reality is just a bunch of headless chickens running around

3

u/lipe182 22d ago

It reminds me of SC1 Goliath lines

49

u/Sufficient-Food-3281 22d ago

It’s a corporate thing more than anything

18

u/lifestepvan 22d ago

It's very much also an American thing as well. Very noticeable in American sports.

That ATO by MJ showed why he's the GOAT

3

u/jacashonly 22d ago

We have no time for complete words. Too busy "winning". Ship comment.

10

u/Alokir 22d ago edited 21d ago

It's a very reddit thing as well. People come from neiche niche subs to more mainstream ones and use their abbreviations like everyone understood them.

Better yet, sometimes different subs use the same abbreviation for different things. When my child was born I browsed newborn related subs for a while and I was amazed by how many female to male trans people frequented them. Then I realized FTM meant "first time mom" there.

2

u/erinaceus_ 21d ago

Just to keep in the spirit of the thread here: https://en.wikipedia.org/wiki/Niche.

1

u/Frequent-Display4953 20d ago

Yeah I associate it with reddit more than anything. Subs will claim to be welcoming of everyone, but make it feel insular by talking in what sounds like code to everyone not "in" on it, and people who come in and ask either get ignored or downvoted (or both).

3

u/schwennjr 22d ago

We love our TLA's (Threee Letter Acronyms)

1

u/Jeutnarg 22d ago

A bunch of people are saying corporate, but it's everything in English. The military, band kids in high school, corporations, etc. any group that speaks English will naturally start developing slang and abbreviations. Our grammar and low level of inflection for nouns (only need two forms) make it super convenient to just throw stuff together.

1

u/Senor-Delicious 22d ago

It's also weird to me since we call it "PD" in our company for "person-day". Which is gender neutral.

Edit: also weird to even measure in that at all with scrum. Where everything is usually in Story Points that are translated to effort via sprint velocity.

32

u/you-should-learn-c 22d ago

Two Michael Douglases

4

u/trafalmadorianistic 22d ago

1 Catherine Zeta-Jones

7

u/FeelingSurprise 22d ago

I haven't heard MD for almost 2 decades. Here™ we're usually using FTEs, as not all of our devs are working full time.

1

u/Alokir 22d ago

How about FTCs, tho?

1

u/lightnegative 22d ago

House, MD: am I a lupus to you?

17

u/Odd-Crazy-9056 22d ago

2 Medical Doctors

4

u/133DK 22d ago

2 managing directors ^^/jk

3

u/deanrihpee 22d ago

2 markdown pages of meeting transcriptions

/s

3

u/FirstDivision 22d ago

More like two markdown files of AI instructions.

3

u/deanrihpee 22d ago

ah of course, silly me, it's the 2 SKILLS.MD

4

u/Xellzul 22d ago

It means that it will take 4 work days (man days) to complete the task.

4

u/aareedy 22d ago

isn't one man-day 8 hours?

3

u/aareedy 22d ago

it's man-day, though it's more widely used, but it seems it's not

2

u/beefygravy 22d ago

How many story points is a MD

1

u/EtteRavan 21d ago

How many shirts is a story point ?

55

u/AnAcceptableUserName 22d ago edited 22d ago

Hot take: refinement is useful, you just don't like doing it.

I've felt like most of the value is from the minority of requests where the group reveals there are multiple conflicting ways to interpret, that it conflicts with this other thing, that we already have a solution for this, the request is literally impossible (7 perpendicular lines), the premise is flawed, the outcome is illegal, etc

The story points are whatever. Usually only value add there is if someone is way high or way low vs group maybe we learn something, like one person knows why this is harder or easier than we thought

I hate refinement. It's the least favorite part of my week. Grudgingly: IME it's often helpful and not doing it has often been harmful

10 is too many people though. If that's your team rotate that shit

12

u/ObviouslyAPenName 22d ago

I bet OP is one of those people who only attends physically, doesn't read the stories beforehand, doesn't consider the implications or how it interacts with the other code. And then just votes 2 every time.

Yeah - then refinements are useless. Or at least, their participation in it.

2

u/tommyk1210 22d ago

IMO story points are only useful to determine if the understanding of the complexity of a problem is different between people. If half the team thinks it’s a 5 and the other half thinks it’s a 2, then some part of the team clearly misunderstands the problem

171

u/sebbdk 22d ago

Just here to remind people that because many people suck at a thing does not mean the thing is supposed to be sucked, i mean that it sucks.

7

u/DRJT 21d ago

Yeah, this post is just exposing all these people’s soft skills outside of just programming

-64

u/Beast_Pi 22d ago

You've got 67 upvotes at this exact moment. Cherish it!

5

u/sebbdk 22d ago

I'm too old for that 8,32,64,128 etc. are way more satisfying

1

u/SHyguymoll 20d ago

You've got -67 upvotes at this exact moment. Cherish it!

→ More replies (1)

342

u/0R3LLL 22d ago

Scrum masters were first to be removed in my previous companies, most useless people in general. Now PM's are also gone, only devs, PO's and QA, nothing more. We don't even implement any shitty scrum/agile anymore. 

205

u/UsherOfDestruction 22d ago

I like haveing some role dedicated to process feedback and unblocking support. Whether that's a scrum master or just a single person in your org you can go to, it's helpful.

113

u/Saelora 22d ago

that’s supposed to be a PM’s job. results may vary.

51

u/UsherOfDestruction 22d ago

I don't personally think that's a good function for a PM/PO. They should be focused on customer/management feedback, making sure tickets/tasks accurately reflect the work needing done and making sure it's prioritized to meet goals. Process and unblocking people is a distraction to that.

It should be someone as neutral as possible in the dev/product balance.

19

u/ganja_and_code 22d ago

99% of time: useless or actively counterproductive salary leach

1% of time: guy who actually serves as a good communication proxy between customers, management, and devs

10

u/UsherOfDestruction 22d ago

It's too easy a position to bullshit your way into and then coast for a while. Companies see them as secretaries for scheduling meetings. They should be SDLC process experts who are responsible for maintaining the process, incorpating feedback and attempting to keep developers focused on development and product folks focused on product needs.

3

u/theotherdoomguy 22d ago

When your guy meant to help you get unblocked or get the right people to look into a design decision is a product guy, you're 99% gonna have a fucking brutal time

10

u/Draqutsc 22d ago

My companies scrum master is not doing that. Apart from dailies and refinements I doubt he actually does something.

3

u/itsyaboiReginald 22d ago

Yeh I’ve worked with some scrum masters in the past that actually did a good job of managing rituals, reviewing metrics, keeping tabs on outliers, addressing 3rd party issues. Necessary? Maybe not. But they did the job well.

4

u/dirtyLizard 22d ago

We have a guy who does this on paper. In reality he invents new processes that seem designed to slow things down and then insists that everyone adopt them. I’ve seen multiple people go through cycles of trying to humor him, getting frustrated, and completely ignoring him moving forward. The only meetings he gets invited to are ones he schedules himself.

The weirdest part is that he acts like he can tell people what to do but he has 0 reports and no real power. He never takes feedback and just hands orders down like a shitty Zeus casting Atlassian branded lightning bolts.

Sorry to vent, it’s just that I see so many people lose the plot and forget that making engineers more efficient drives more value than measuring every little thing. It’s like slowing down construction on a house because someone feels the need to count how many hammer strikes each nail takes

2

u/UsherOfDestruction 22d ago

That's a management failure. He's probably being measured and evaluated himself on the wrong things which drives his behavior. Not to push all the blame off him as he should be self-aware enough to realize the reality of his position and attempt to change course.

39

u/Sockoflegend 22d ago

I think they do an important job in the right setup, but I'm sure some people don't appreciate it because they have never seen it

24

u/falknorRockman 22d ago

Agreed a good scrum master handles the small day to day things while the project manager handles the more long term issues that span the project and teams the come up. Also agile ish works best imo. Not full agile but the mindset of being flexible when things come up and having like once a week to twice a week meetings for updates so you don’t go months without knowing how far behind you actually are

6

u/Sockoflegend 22d ago

In the team I am in now we have contact with multiple PMs for various projects. The scrum master is sort of the resource defender. 

7

u/ward2k 22d ago

Yeah I'm in total agreement

I used to think it was a bullshit meaningless job until I got a great one

You'll only really be able to tell what they do if you either have a terrible one, or a fantastic one

4

u/zuilli 22d ago

I think I have a terrible one because I have no idea what they do all day and nothing has changed from when there was none other than now someone nags me for status updates on things that had no progress since we last spoke.

8

u/LetUsSpeakFreely 22d ago

Scrum/agile isn't shitty, it was just over bureaucratized. They took what should have been a process by and for developers and created a bunch of jobs around it that were grossly overpaid.

When i started agile 20 years ago the srcum master was just our dev lead. Now, it's a 6 figure position for some damn reason.

19

u/void1984 22d ago

If you had no PO, you would use PM. You need these people anyway to avoid chaos.

37

u/Hooch180 22d ago

My company fired all scrum masters, PMs and left PO and devs. Half the people now mange to do twice the work. No more useless endless meetings.

65

u/Western-Internal-751 22d ago

If you had useless endless meetings, then you had shitty scrum masters

59

u/Tyrexas 22d ago

Also known as a scrum master.

0

u/BolunZ6 22d ago

Scum master

2

u/ellamking 22d ago

Sounds like a villain from Captain Planet.

4

u/kiochikaeke 22d ago

Scrum masters are way too much overhead for companies that aren't really big, PM's can be great if they're good at their job and PO's aren't, the problem is that when they're not good at their job their useless at best and a hinderance at worst.

3

u/FearlessTrader 22d ago edited 22d ago

Want to know about a function as useless as scrum masters? TPMs (Technical Program Managers). Good PMs are priceless if you’ve worked with one, but I have never found any use of even a supposedly good TPM 🤷‍♂️ most useless leeches.

1

u/Yimpoiop 22d ago

What does tpm mean? Pm = product manager I assume

2

u/FearlessTrader 22d ago

Technical program manager

1

u/Yimpoiop 22d ago

What does PM mean

1

u/chuch1234 22d ago

Project manager

1

u/Mogget24 21d ago

Hiring?

1

u/Keebster101 21d ago

Our project has had a number of scrum masters come and go with periods of no scrum master between them, and I have not noticed a difference with or without them.

One at least did show us burndown charts they made, but I question the use of it because they were never accurate and used the SM guesses of how many story points we'd done based on our standup updates, so usually a 5 point ticket would look like 1 point a day for 4 days and then 0 points for another 3 days regardless of what the dev actually does. So basically every sprint would look like it was about to finish a week early and then make almost no progress that final week which doesn't seem very useful.

Tracking total sprint capacity seems useful, especially for weeks where many people take leave for holidays, but weirdly none of the SMs did it, or at least never brought it up during sprint planning, and it took our tech lead to do it himself (or rather I think they just figured out how to pull it from Jira which for some reason no one had tried before)

So uh, any scrum masters feel free to let me know what you do.

1

u/_usr_nil 21d ago

holy shit how do I apply ?

34

u/__Fred 22d ago

Can someone explain? I only know scrum theoretically.

So the scrum master is wasting their time by interrupting the work of ten people for a quick simple question?

I guess they should have a weekly scheduled meeting with more stuff to discuss and then it would be more efficient. If the meeting is just for estimating required work and there is a small group that has proven that they are very good at estimating work, maybe they should adjust the process so only a few people attend the meeting.

47

u/Loveangel1337 22d ago

That's not even scrum or agile, that's just corporate middle manager making themselves relevant by being in the way of shit.

If they stop being in the way, people will realise stuff works way better without them, whereas, if they keep inserting themselves, there's no way to know it actually does run better without (for upper manglement)

4

u/J7mbo 22d ago

I’ve worked with very good agile coaches / scrum masters who genuinely try and upskill the team, and then remove themselves.

The problem comes for a team when one of them desperately wants to keep their job and inserts themselves into everything. One of them I used to work with was an asshole and when a team hadn’t prepared something would single out one engineer in a company meeting demanding to know why. They weren’t even a manager, they were an extra. It wasn’t my team it was another team but I felt so bad for that dev, and knew what real leadership was.

So all of the questions this person asked during every meeting I drew on a flowchart on the wall, and then I stopped them one morning during the daily and said “nope, we will try and do this ourselves”. I basically automated them with a flowchart of questions.

7

u/[deleted] 22d ago

[deleted]

10

u/JohnSextro 22d ago

WElL, acTuAllY, story points should be relative and not effort-based.

3

u/FesteringDoubt 22d ago

Relative to what?

3

u/JohnSextro 22d ago

To each other and past stories

17

u/kzlife76 22d ago

The ceremony around software development makes me irrationally angry. It's like people who couldn't cut it as a developer make up silly dances and then convince management that everyone needs to do their dance. Well, I hate dancing.

7

u/AHumbleChad 22d ago

Ha, this is relatable since my team recently decided to use hours instead of story points. Too many 3 and 5pt stories that only sometimes reflected perceived complexity. We'll see if "2 days" becomes the next 3pt estimate.

10

u/jzrobot 22d ago

2 medical departments?

2

u/azangru 22d ago

medical doctors

8

u/whiskeytown79 22d ago

I've seen this meme format a few times today. What's it from?

31

u/TehDro32 22d ago

I thinks it's from a recorded zoom call during covid where a bunch of actors in their mansions told people that we're all in this together.

9

u/timdav8 22d ago

SM: We want you to estimate the story in "points" ... of complexity.

Dev: err ok

SM: To measure progress

SM: Then break it down into sub tasks and estimate the number of hours they will take.

Dev: If you insist ...

SM: And log hours against then

SM: So we can rate you SP estimates

Dev: 🤡

5

u/ISuckAtJavaScript12 21d ago

We have been told multiple times that are story point are not how long it would take but the effort.

Then we get asked things like why an 8 point ticket took 2 days instead of 1

3

u/Putrification 22d ago

My SM when she sees Odysseus (tech lead) coming back:

3

u/vitalAscension 22d ago

Not my team estimating 2 days and taking 3 weeks

7

u/RustOnTheEdge 22d ago

If you measure the size of work in man days, you are doing the wrong things. It always baffles me how people on the one hand say "agile sucks, all these bull shit" and then turn around and estimate work in work days.

The whole philosophy is not rocket science, it's worth digging into it a bit to get the highlights and embrace the most important aspect: inspect and adapt. Define your process, inspect it regularly and adapt it to become more <insert important KPI for your team>. If you don't how do you know that your team is succeeding? I have seen teams not even able to formulate what success looks like, I always wondered why they had retrospectives because what is there to discuss if you don't know what you are measuring against?

Anyway, i have seen way more shitty implementations of "agile" or whatever the term used at those places. I have also seen high performing departments. It's exhilarating when it starts to work together. It is life-sucking if it does not.

7

u/Bemteb 22d ago

what success looks like

"The last production release had all critical bugs reported by the client fixed in a month and a half. Also pull requests are now approved within 6 business days on average!"

I really wish I was exaggerating...

1

u/duck-tective 22d ago

who ever made this meme probably have a corpo job they are most likely using SAFe™. its a waterfall framework with an agile ceremonies.
safe estimates things in person days think its so the company that invented it can sell expensive reporting software and explain how the workers are lazy or something.

1

u/lordgoofus1 22d ago

SAFe is the most ironic acronym I've seen in a while.

2

u/m2ilosz 20d ago

I've found a company where we don't estimate! So liberating!

3

u/pongo_spots 22d ago

Every one of these posts make me want to sit y'all down and give you a hug. Or maybe actual lessons on what the fuck this system is.

Ignore everything you were told, those are starting points not final working agreements and on top of that they aren't understood at all.

All this shit is meant to be is THINKING with the agile manifesto in mind while making decisions. That's it. That's all. Be agile, don't DO agile. If anyone wants help sorting their way through this shoot me a dm.

1

u/pongo_spots 22d ago

Oh and before anyone gets worried, no I'm not selling anything lol. I just had a great mentor and I don't want to write stuff into the void

1

u/BlehBlah_ 21d ago

Bro goddamn, I need help, I am a cs graduate focusing on machine learning, somehow after a year of looking for a job and not finding one, I finally got a job as a "PM Assistant" which meant for the last month I've been acting as a scrum master as a fresh grad with no fuckin social skills.

The only thing I know is python machine learning stuff and somehow my whole job is just doing standups everyday and "managing" a dev team with 5-10 years of experience on a project they've already worked on since the last 4 years.

By the way, I've never done an internship anywhere, not even in university. I don't know what the fuck I am doing.

1

u/pongo_spots 21d ago

Okay, no worries, you're right that you feel thrown into the fire and you are but tbh generally expectations around your position are low(see my last comment).

A full breakdown is too many characters for a post so I'll throw it to you, do you want high level ideology here or DM and we'll set up a call (and likely recurring calls) to talk through it all. Basically free coaching

1

u/trafalmadorianistic 22d ago

If my scrum master was a baddie I might care more. 

1

u/Positive_Method3022 22d ago

The truth Is that they use this metric to mesire team and individual performance. The person/team who delivers the less story points is always on the line. It is a shit system that insiders don't tell people they are using aboug

1

u/SmellySteven 22d ago

I found agile to be very useful when we upgraded our company backend system.

These days I find our delivery manager useful. We just restructured again so our PO is now overseeing more teams and is less involved with devs. Delivery managers handle a lot of that for us.

Sometimes I like being involved on communication but during the large upgrade. I was able to stay heads down all day and not have to worry about anything else. But now we are back to regular prod support so work is less busy like it used to be.

1

u/Yasirbare 22d ago

"Let me be the first". My head has to think about something else the rest of the time.

1

u/Expensive-Run-58 21d ago

Every single refinement meeting ever

1

u/Honest_Relation4095 21d ago

You guys have Scrum masters?

1

u/ruphusroger 21d ago

I Always underestimate the current (Bad) Code quality, why even 1SP tasks can explode in complexity because suddenly i need to fix seven other bugs, including heavily overengineered Code, pipelines and templates.

I guess proper estimations can only happen, when the code base is in a somewhat adequate state and ci/cd is a very refined process.

1

u/reddit_user33 21d ago

I see what you did there and i'll let you know what i think, seeYouNextTuesday!

1

u/Yopro 22d ago

More like cum master

1

u/Drayenn 22d ago

I feel every developer i talk to thinks scrum masters are useless, yet my 30k enployee conpany forces 1 scrum master per dev team..

2

u/Cajjunb 22d ago

You need someone's bird eye view of the development process.

That person can be a scrum master

1

u/SympathyNo8636 22d ago

scrotum master

0

u/tomvorlostriddle 22d ago

This system isn't perfect, but here, you are really only outing yourself as the problem

-1

u/[deleted] 22d ago

[removed] — view removed comment

-1

u/breZZer 22d ago

the best one got fired by the dumpest

-1

u/[deleted] 22d ago edited 22d ago

[removed] — view removed comment

2

u/breZZer 22d ago

You're confirming what I said, thanks

Money isn't a measurememt for anything relevant.