You must log in or register to comment.
We have the one hour daily meetings we call “standup” 🙄
Right? Minute 55-60 is the 15th minute. Fuck that. If it takes that long then the team is too big for agile or the scrum master had lost control.
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.
Obligatory, since nobody else has linked it https://www.youtube.com/watch?v=BKorP55Aqvg
Let’s not forget “We need this right away!” then it takes weeks to deploy because the people who requested it weren’t actually ready for it yet (if they don’t change their mind and decide they don’t actually want it at all).
“Its not in the budget to apply security patches this quarter”
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
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.
Story points = hours
4 hour planning
I’ve seen projects where this was comically too high. But a lot more where it was horrifyingly agonizingly too low.
It’s actually not a crime to mercy kill and dispose of the body of anyone who says “Well, it’s a simple task. Are you having difficulty?”.
It’s an obscure and weirdly specific law.
(This is a joke, of course.)
I have spent the past 20 years cultivating a variety of tones in which to utter my standard reply to such nonsense:
“Cool. You do it then.”
That’s a great way to handle it.
I like to pass them the ticket and schedule the next open hour on their calendar for them to teach me how to do it, if they’re a developer. Sometimes they do, because I was genuinely missing something easy. Usually they get to awkwardly discuss why they don’t have it done yet, either.
When the person isn’t even a developer, I’ll explain the usual process between developers, and give them a chance to beg their way out of it.
If they don’t beg off, I schedule them anyway and see if they can actually at least “rubber duck” me through the problem. (Sometimes it even works.)
I’ve had a couple peers discover (or rekindle) their love for development this way. Most just make up a reason not to make the meeting, though.
So what’s the actual error margin for estimating feature implementation time? It’s going to be nearly the whole thing, right?
The estimate is not a promise, it’s a guess. I prefer to estimate in sprints because that’s about the resolution we can have confidence in, but management want hours so my process is to estimate the number of hours in a sprint (73.5 for us) plus one sprint
200% overruns are common, especially when requirements change significantly
Wildly depends on the complexity of the feature. If it only takes 4 hours to implement, you might have good enough of an idea what needs to be done that you can estimate it with 1-hour-precision. That is, if you’re only doing things that you’ve done in a similar form before.
If the feature takes two weeks to implement, there’s so many steps involved in accomplishing that, that there’s a high chance for one of the steps to explode in complexity. Then you might be working on it for six weeks.
But yeah, I also double any estimate that I’m feeling, because reality shows that that ends up being more accurate, since I likely won’t have all complexity in mind, so in some sense my baseline assumed error is already 100%.
Hmm, so kinda O(n1.5) scaling? (Of the ratio between definitely required time and possibly required time, anyway, since a -110% error wouldn’t make sense)
Really not sure an estimate for algorithmic complexity is the right way to specify this. 😅
But if your supposed input unit is days, then I guess, yeah, that kind of works out.
Might as well put the whole Agile/Scrum crap on there while you’re at it…
Disagree. My company does it well and I think it helps productivity across the board. My last job called our process agile and it was really just water-scrum-fall. Which was horrible and we devs were all miserable.
My experience with it was not like that… resources were thin but decision makers were poor at managing and simply wanted to take in the buzz to make it seem like they were doing better than they actually were. They could’ve made another Office Space movie about us. Needless to say, it’s no surprising the CTO left and later on the top division chief left… all the while, management kept putting pressure on making sure we fulfilled the caveats of agile/scrum even though we didn’t have the bandwidth to do all of it. Documentation is important, sure, but when management makes everything a P1 just cuz they failed to see things though… well, don’t find the time to put everything down in the kanban… yada yada yada. No thanks
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.
I just had a contractor tell me I needed to prioritize their request because it’s urgent for the task they’re working on that’s adding a new feature.
they want me to push the changes out by EOD…today…Friday.
I don’t like to do this, but I hold seniority…sooo…I think I’m going to take a three hour long lunch and cut out for the weekend early.
don’t come to me with a request unless it’s actually urgent.
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.
Special prize for blackout?
A pizza party from 12-12:30, perhaps?
12:15. And you bring your own pizza. Best we can do because budgets been tight after we spent 7 million dollars on the new 3rd party software system. It’s turnkey and will solve all our issues right out of the box though.
turnkey /tûrn′kē″/ noun
-
The keeper of the keys in a prison; a jailer.
-
A person who has charge of the keys of a prison, for opening and fastening the doors; a warder.
-
An instrument with a hinged claw, – used for extracting teeth with a twist.
Sounds about right.
-
