- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
”All features are xy problems”
”PM adds new features to the sprint faster than they’re solved”
”Each release require two weeks of testing”
”Each release introduces new bugs for customers despite the two weeks of testing”
I would share this with my dev team
But the teams “scrum guide” and “product owner support” are on the chat and it would get my ass fired
I prefer the inclusive term of “Scrum Dumpster”. It really works.
One of these is wage theft. Don’t enable that shit.
Yup. Not getting paid? Don’t work.
Forced to? We have a word for someone who is forced to work for no compensation… The word is slipping my mind, but I’m pretty sure the USA fought a civil war about it.
Does 5 time trackers count as 5 points ?
4x4 bingo?
Bing (or I guess to keep up with the song, _ingo)
The “Story Points = Hours” hits so goddamn hard. Like, tell me you don’t fucking understand scrum without telling me you don’t understand scrum.
We had a nice, effective production process on my team until a middle manager assigned to communicate with us started in with the whole “We can’t spare this many points” bullshit.
Guess i got a blackout bingo on this one. Oof.
deleted by creator
Unpaid overtime = work is just not going to be done.
That’s what I do at work, even though I’m salary.
Management decided to hire a new guy and then have a round of layoffs within 6 months, effectively canning someone to replace him. Since then, we’ve had multiple times where we have hundreds of tickets sitting unassigned because there’s more work than people. So shit sits and falls through the cracks until someone has time or something is on fire.
It fucking sucks, but eventually the bean counters will see that we actually needed that extra body…
We did have well over 100 tickets in the queue, now they split the support team into multiple sub support teams and each sub team has fewer tickets in their own queue. The total number is still massive but compartmentalising the problem makes most of it go away! I can filter it down to such a degree my queue is almost single figures by just ignoring everything else because that is someone elses problem.
Also my sub team doesn’t have anyone to cover 1st line on some products so I am covering 1st line there as well as 2nd line. Upside is my stats look brilliant now that I am doing all the password reset tickets.
If story points are now hours, I hope you’re fine with me putting a 40 on that ticket.
Storypoints are such an artificial concept it doesn’t even make sense. Same thing with estimation though. Most numbers are “I pulled it out me arse” unless the task is a one line change. And even then, shit breaks and it becomes useless, so the one line change is estimated to be a day anyway
The idea with story points is you assign them consistently, so the team’s velocity is meaningful.
One team might deliver 30 points in a sprint while another delivers 25 and they deliver the same amount of work
Of course management want to be able to use story points for tracking, they want to compare teams using them, so you end up with formulas for how many points to assign
Of course if they score you on points, they get more points, not more work and story points become useless
The idea with story points is you assign them consistently, so the team’s velocity is meaningful.
Yep. But then we got some data and it turned out that story point estimates reliably create a lower quality velocity then simply counting tickets, ignoring their obvious massive size differences.
Any time spent estimating story points, creates negative value.
Sources:
They worked well for us, we were updating a big system or adding functionality to it and a lot of the features were similar enough that we could reliably break the work down to sub-single sprint chunks and assign consistent story points to them
Though I have only been in one team that lasted more than 3 sprints relatively intact, and it’s only that team that got good at story pointing work
They worked well for us
Yeah. I used story points successfully for years.
After learning about the above data, I asked my team to trial just counting tickets for velocity, and it also works fine.
The outcomes weren’t noticably different, so now we just don’t spend the couple hours each sprint that estimating story sizes was costing us.
My team was hesitant to give up story point estimation, because they didn’t want to give up the communication with leadership about which stories were XXL.
So we kept using the XXL issue tag, but dropped the rest of the estimation process.
One time a VP decided to jump in and be a developer and he just pointed a bunch of cards when the dev that was really going to do the work was off for the day. Obviously the points were way too low, so I just padded out the rest of the cards knowing the 7 points on the cards the VP pointed was going to be the entire two week sprint for the other dev and I’d need to to whatever else was put into the sprint.
And that’s how I found out the Product Manager was putting the points into a spreadsheet to track how many points each individual dev was doing. He was actually upset at me for doing 20 points in the sprint. Sure, I padded them out, but why wasn’t he bothered by the cards that had too few points on them? Just upset his spreadsheet was screwed up, but couldn’t be angry at the VP that under-pointed a bunch of cards.
I try really hard when I’m in a scrum master position (my position is pretty chaotic, 20k person organisation, scaled agile, “we need your x skills this program increment, please would you?”) to hide my team’s individual performance from management. Mostly because your can’t compare a system analysts numbers to a mainframe programmer to a mid-range programmer, but also if someone’s not pulling their weight I want to solve the problem within the team where we can approach it as equals before resorting to management “performance review” systems.
Somewhat agree, but since Scrum is supposed to be bent to the team’s needs, it might differ from team to team, but it’s fine as long as those numbers are consistently used in one team.
Story points = hours
PO: “Why does it seem like it takes a really long time to develop new features?”
Dev: “I’m glad you asked! We’ve got this piece of code (points at smoldering pile of spaghetti) that literally has to be changed every time we do anything. The person who wrote it has been gone for like four years. No one knows how it works and it’s central to the entire application. I would estimate that this easily doubles the time it takes to work each ticket. I’ve created a set of stories to rewrite this code. We just need your approval to bring it into an upcoming sprint.”
PO: “Can’t… Hear… Breaking… Up… Bad connection…”
Dev: “Uhhh… This isn’t a Teams meeting. You’re sitting in the room with us right now.”
PO: …
Dev: “We know you’re still here even if you’re not moving.”
PO: …
The person who wrote it has been gone for like four years
Four years? You gotta pump those numbers up. Those are rookie numbers.
I recently learned that a web app I wrote in 1999 (for Internet Explorer lol) is still in use by the company I wrote it for. And this app was basically a graphical front end sitting on top of a mainframe application that dated to the 1970s, so my app’s continued existence means that mainframe POS is still running, too. My app was written in Classic ASP and Visual Basic 6 - I truly pity whatever poor bastard has to keep supporting that shit. They probably have one ancient PC in a closet somewhere acting as the server for it.
“Its not in the budget to apply security patches this quarter”
Do people not know how bingo cards work anymore?
who are these time wasters that just put bugs in their code. I mean come on.
It’s me, I do it. But only when I need something to do to stay awake in hour five of today’s meetings to address the “quick turnaround” patch that I finished coding three weeks ago, but now they want a label to change and no one on the six teams that have somehow become involved seems to know who owns the package that the field the label represents belongs to, but they’re absolutely certain we need to programmatically retrieve the text in case the package owner changes it at some point, and someone remembers that the original developer wrote code to get the label text 16 years ago, but it was removed from the program two years before the project started using source control, and they have an old installer around here somewhere that we can decompile or trace with Wireshark to get the right RPC name (sharing their screen while they have a rummage for it, natch), and someone else volunteers that they might know how to get a version of the server application from around that time since the client and server versions have to match, but it’s technically the intellectual property of a different subcontractor who was just a guy in Alaska who passed away five years ago, but they’re sure they can convince his estate to burn it to a disk and mail it to me if they can just find the contact information…
Move slow and break things
