How to best communicate to management that "Less people => less velocity" is in fact true

[-]

purple_editor_@reddit

Sometimes management will push really hard in order to try to extract extra from the team, and sometimes a new model arises

The way you talk about it, it seems your team is already mature so it is possible that you are at the optimal place indeed.

But if you truly believe there is room for improvement, start by breaking down some paradigms just so that you show management that your team is experimenting. Afterall agile is experimentation as well

One paradigm shift that you can start with is: developers also can be testers. Your remaining QA person may write the test cases for a story but a developer would be the one to get that story and test if the story complexity is below a certain threshold and if the WIP is close to a certain threshold as well

I have seen this work quite well on some teams that suffered with reductions

[-]

UmUlmUndUmUlmHerum@reddit (OP)

That seems like a genuinely good idea to bridge this (maybe short) period.

Having the real testers focus on the big stuff and hand the small fry stories to other devs where the testers only write testcases

Would also encourage us to put in more effort into splitting stories down

I will suggest something like that

[-]

purple_editor_@reddit

Great! Hope to hear from you about good results in the future as well! Good luck

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Well.

After 21 days, two dev resignations and the exact same discussion again (you lost two out of five devs, your velocity should NOT decrease this much! 80% of previous is the lowest we accept!) I also quit.

So sadly no good results to be found :D

[-]

purple_editor_@reddit

Oh, sorry to hear that OP Management is really fucked there then. Hope your next endeavor is less stressful and more rewarding

[-]

bobaduk@reddit

Just wanna say, you're handling this like a champ, and I love how engaged you are with the suggestions you're receiving. If this is fixable,.then you've got this.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Sadly, it wasn't fixable

After 2 dev resignations and the entire same discussion ("Why does your velocity go down if you lose both QA AND Devs?? Keep it at 80%!") I also handed in my 1 month notice :D

[-]

bobaduk@reddit

Sorry to hear that, friend. In the unlikely event that you're in the UK and still looking in a few months time, keep an eye out for Carbon Re, who would love to hire a high-agency, organisationally savvy engineer that can assimilate feedback graciously. Their loss :)

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Thanks!

Even if it is a not fully fixable issue (which I do suspect), there is nothing wrong with treating it as a chance to grow - by thinking about your proposed solutions to all of this.

[-]

xKommandant@reddit

This is what happens when you put non-technical people in charge of technical projects. They somehow reverse “adding people to a project will not immediately improve productivity” into “removing people from a project will not immediately decrease productivity.” Godspeed.

[-]

CodrSeven@reddit

Ew, I've learned to stay the hell away from orgs that track velocity/points, that's not how you build quality software imo.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

we build ok software at ok but predictable intervals

[-]

CodrSeven@reddit

Sure, but its all based on pretending, isn't it?

Pretending to have deadlines and pretending to have a clue how long something is going to take before building it.

[-]

specracer97@reddit

Inform leadership that they made the decision for 70 with reduced headcount.

They have the choice of staff for 90 or accept 70, and remind them that attempting to force 90 from a team of 70 will result in 70 dropping as attrition forces them to rebudget to be able to hire back up to reach 70.

[-]

calima_arzi@reddit

Ask your manager, are they asking for team members to work longer hours? A reduction in quality and build up of technical debt? They'll probably say 'neither' but it's worth asking.

Finally are there any changes that could be made to start closing the gap from 90 to 70? Any time wasting processes you want rid of, or have not been able to automate? You may be able to haggle if so.

[-]

fragglet@reddit

Well, your first mistake is sharing velocity/story point data outside the team. That's for your team and as soon as you start using it as a management tracking metric you endanger the integrity of the agile process.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Well, your first mistake is sharing velocity/story point data outside the team

Genuinely we have no choice - management demands this and uses it as a KPI to compare teams. Publicly. PI-Planning has a diagram where team-velocities are compared

[-]

fragglet@reddit

Oh, you're using safe, I missed that detail. Well, you have deeper problems then.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

We're using SAFe for a overall departement of 20 Devs and 10 Testers - it is genuinely funny how wildly unfit the whole process is

[-]

bobaduk@reddit

A 2:1 ratio is high, can I ask what domain you're working in? It might honestly be that you can find ways to improve productivity and get some utility from this nonsense.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

insurance

it might be a high ratio - but beforehand we (in our subteam where we had 1:1 ratio) had it balanced to where the testers managed to test the things we produce pretty well with only minimal downtime for either devs or testers.

That kinda tells me that each and any change in this equilibrium needs to be very well considered

[-]

serpix@reddit

Do you have any test automation? 2 devs per qa gives me an automatic eyebrow raise.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Not enough, no

[-]

anubus72@reddit

automated tests should be written by the devs for every change, its not something that you assign other people to do

[-]

UmUlmUndUmUlmHerum@reddit (OP)

automated tests as in automated end-2-end tests right?

because of course we write unit/integration tests which are part of our CI/CD pipelines

[-]

anubus72@reddit

If you guys already write automated tests for every change, I find it pretty hard to believe that you need so much manual QA.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

had abit of s dig asking highly tenured coworkers about the issue:

That every single ticket needs to be retested by them as if no tests were done by us is an artifact of an older time a few years ago where dev quality was really bad.

Current situation is the result of that. We could probably get away with letting our testers just be a bit sloppy

[-]

pag07@reddit

In some domains like insurance or banking it is not feasible to find bugs by rolling out and monitoring your users.

In those cases there is also a strong point in the seperation of testing and implementation. Depending on regulation a PR review by a coworker might not be enough.

[-]

bobaduk@reddit

Sure, any change needs to be considered, and will impact delivery. Teams are like ecosystems: they get richer and more productive the longer you leave them alone, and when you take a chainsaw to them, they grow back differently.

I'm just saying - with no sense of judgement - that's a very high ratio. Is your work primarily UI intensive, or are you working on the business logic side of things? What's your automated test coverage like? Are testers responsible for automation,.or is that a shared competency?

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Is your work primarily UI intensive, or are you working on the business logic side of things?

Currently mostly blowing up/refactoring some key services in our monolith in preparation for follow-on-features

What's your automated test coverage like?

Horrendous - but we got some dedicated people assigned to improve things there.

Are testers responsible for automation,.or is that a shared competency?

We got some dedicatied test-automation people, they are the only ones doing such things

[-]

bobaduk@reddit

So this is what I'm hinting at elsewhere: the situation is fixable if you get your release and testing game up to par. You can probably go faster than you did before, though it would require management buy in and time. If they're sticking to their guns re headcount, your smart move is to say "you're right, we'd like to improve our productivity and rely less on manual testing, but we need to invest for that to happen."

Uh given your other replies in this thread, I am not confident in your chances of success, but I suspect there is sizeable value on the table if you can get people to listen.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

longterm? I agree.

Maybe even midterm (I genuinely think in 6-12 months real good progress might be made with a bit of focus)

But the point of contention is our short term velocity for the next release :D

The suitable next question I should ponder is probably "how can I get management buy-in to automation?"

[-]

bobaduk@reddit

Outline the options in an email, expect a bit of shouting, patiently explain the trade offs, and say "you're the boss,.you have to pick the option, or propose an alternative,.I'm just the messenger"

[-]

UmUlmUndUmUlmHerum@reddit (OP)

yes, that seems like the way to do - I just need to run the numbers and talk to some peers in the company and get some estimates by more people I think.

Building an "alliance" of likeminded people so that it doesn't just come off as my own pet idea

[-]

Fair_Local_588@reddit

Also used to work for an insurance company running SAFe. Just wanted to wish you godspeed.

[-]

BanaTibor@reddit

I have worked in SAFe for at least 5 years, in a \~50 dev RnD, SAFe was unfit for that too. It just has so much administrative overhead it is useless.

[-]

MaximusDM22@reddit

Crazy that such a small department is so focused on tracking worker productivity. I feel like they would have bigger issues to worry about.

[-]

hailstonephoenix@reddit

It's not for the benefit of the team. SAFe exposes team velocity to upper management in the form of KPI tracking and micromanagement. The scaling part of it is for the purpose of "aligning" multiple departments.

[-]

drunkandy@reddit

20 devs on a single team seems high, is that all the devs in the company or just one team? If it’s all the devs have you considered splitting into smaller teams?

[-]

UmUlmUndUmUlmHerum@reddit (OP)

oh 20 devs is the entire departement of 5 teams - imo the team composition is pretty alright

[-]

wskttn@reddit

That’s exceptionally stupid. This company is fucked.

[-]

large_crimson_canine@reddit

We have this, too. But the whole process is fucked. As soon as metrics become the target they cease to be good metrics.

[-]

oupablo@reddit

Seriously. What kind of moron thinks this makes sense? I'd 100% just double the points of all my tasks for my team and then ask for raises since we have double the velocity of everyone else.

[-]

captepic96@reddit

"Fixed button styling" - 2500 story points

Our velocity is approaching one million story points per sprint. Inflation, sorry.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

One of our co-team-POs constantly gloats about how "they overplanned by 1x0% but we commit to this number and pull it off" in the PI-Plannings in a public presentation

It is actually hilarious - but we never bothered with such bs

[-]

Hyronious@reddit

Co-team-pos? Does that mean you have multiple POs to one dev team?

[-]

hailstonephoenix@reddit

Yeah it can happen when your team ends up silo'd on a few different projects with different PO's/process/timelines. SAFe is actually a cancerous bastardization of Agile to wrest control from the team to upper management.

[-]

Hyronious@reddit

Sounds pretty rough, glad I've been lucky enough to spend the vast majority of my career in departments working almost entirely on single projects

[-]

-town-drunk-@reddit

I know you said you don’t want to do it - but just game the system and inflate points.

Your management is already clueless if they a) expect story points to mean the same across teams, and b) use that to compare performance across teams.

So just lean into their nonsense and give them what they want.

[-]

shaliozero@reddit

Using complete imaginary storypoints to compare performance across different teams is a new one to me... It's like using air temperature to compare vehicle speeds. You can surely find a correlation, but it's too individual to use it as a metric for something its not a unit for.

[-]

BanaTibor@reddit

Do not have illusions they do not care about story points. In their sp is converted into time. At my previous workplace it was 1 sp = 1 day. With fixed release dates and fix content agile goes out off the window.

[-]

young_horhey@reddit

I'll do you one better, a friend of mine works at a company where they bill the customer based on how many story points...

[-]

shaliozero@reddit

That's at least somewhat reasonable if it translates into a predictable time spent to agree on a first payment. If they billed them afterwards based on the initial storypoints though...

We used story points for tracking working times. For a month. Then they realized that's a very bad way to get employees logging their working hours and fucks over project managers.

[-]

michalproks@reddit

Really depends on how story points are interpreted. I’ve seen implementations where story points are not abstract and it’s just 1 SP = 1 man-day

[-]

KnaveOfGeeks@reddit

That's still not concrete. A day's work can vary wildly even for the same person.

[-]

Sevii@reddit

It's bog standard in corporate America.

[-]

DjBonadoobie@reddit

Precisely why "metrics becoming targets themselves" is problematic.

[-]

Narxolepsyy@reddit

Some execs just can't handle not having metrics for everything so things can be put in a slideshow and eventually see "line go up or down".

I once had a logistics job that put in a phone call metric and requirement... Despite the fact that I might deal with companies I email or simply less workload that particular day. Didn't matter, we'd get told to increase call count.

[-]

Mikefrommke@reddit

Do this. It’s not like you need to double everything. All ties round up. For half the stories each sprint increment one unit.

[-]

lxe@reddit

You can just make up the numbers to satisfy useless contrived metric requirements and focus on real productivity in the meantime.

[-]

mizdev1916@reddit

Start inflating the points of your tickets and suddenly you'll be hitting higher velocity

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Maybe a very gentle point-inflation could solve the problem over time. Adding a single point here or there. Splitting stories further and round up both times etc

[-]

fschwiet@reddit

You're thinking too small. Multiple every story point by ten.

[-]

mizdev1916@reddit

Exactly. Play the game and pad out the tickets.

But also, management can’t just cut the number of devs or QAs on a project and then be confused when the velocity drops. It’s utter stupidity and in some ways ‘fixing’ the problem lets them off the hook.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

yeah that is the other thing - I really kinda want the whole thing to go wrong because otherwise we're signalling mgmnt that they can increase velocity by pushing us into several meetings.

I want to be able to say "see we fell short because middle management pressured us into more storypoints" towards the even-higher ups

[-]

mizdev1916@reddit

In which case, put in your hours, quietly encourage your less experienced colleges to do the same. And wait for shit to hit the fan 😄

[-]

the_electric_bicycle@reddit

This is why systems like this suck. You have no reason to believe other teams are also not inflating points, because it can be detrimental to a person’s career not to inflate them.

[-]

TheGonadWarrior@reddit

Your management has no idea what they are doing then unfortunately. Now you just have to play the game

[-]

BudgetStorm@reddit

Which is text book example of using wrench to hit nails...

I'm sorry, but if this is truly your situation, you have already lost control and the top management can do what ever they want and believe or not anything they like.

You can try to explain that the total effect is not in the one position alone. Everything after the qa is slower as there is less stuff coming through and everything before qa is slower because there is no point in pushing more into the pipeline. Constraints are not local, they affect the whole process.

But sounds like they have no intention to believe or understand.

[-]

Western_Objective209@reddit

Increase points assigned to tickets by roughly 30%?

[-]

brainhack3r@reddit

Keep two copies of your books :)

Have two agile systems!

One for your boss, one for you.

[-]

onafoggynight@reddit

Let me tell you: upper management doesn't give a damn about SP really.

That's a sandbox measure in safe. What they care about are real world numbers in terms of cost, deadlines, and value delivered. So, unless you change the frame of the conversation, you are playing a losing game (and allow arbitrary pressure to be piled on).

[-]

Legitimate_Plane_613@reddit

Using velocity to compare teams, a mistake as old as scrum.

[-]

Master-Broccoli5737@reddit

Tell them tough cookies, they'll have to live with it. You're now in the FAFO/ game theory phase of this. They have one method of keeping things going, you better do this or you will find out. You are stuck, you cannot magically produce more. So you need to realize you have only one remaining move. Take this on the chin, but let them know. Your team is high performing, still produces without the needed resource, point out if anyone has picked up extra work and put in extra time to help out. Don't let them hold you hostage to fear.

[-]

xcrszy360@reddit

What is the alternative then? Managers need some sort of KPI to present to shareholders, specially if there is an overall pressure for more efficiency

[-]

prescod@reddit

Many people use DORA metrics, if they insist on metrics.

[-]

carsncode@reddit

Shareholders don't care about story points, that would be a completely ridiculous KPI to present to them. You might as well give them your engineers' WPM. Actually WPM might be better because there's a chance they'd at least know what it means.

[-]

digitalhuxley@reddit

What better KPI to use than a bunch of imaginary non fungible numbers, that represent people’s guesses of work they haven’t done yet!

Could try DORA

[-]

bobaduk@reddit

Shareholders do not care about story points. They care about cashflow. If you delivered a project that reduces cloud spend by 15%, that's shareholder-worthy; if you increased conversion on the checkout page by 4%, party time.

If you got an extra 10 points of velocity, literally nobody cares.

[-]

Legitimate_Plane_613@reddit

The problem with story points is that they are only meaningful to a particular team. They do not translate across teams because different teams will come to different understandings of what a particular point for a story means.

The ubiquitous approach to normalization is to ttanslate points to time, but then we all know that is a fools errand.

[-]

ub3rh4x0rz@reddit

KPIs should be grounded more directly in customer value, not abstractly linked through "oh well stories are grounded in customer value so we did it".

Story points as a KPI is ridiculous, it incentivizes pursuing inefficient solutions, among other things. There is no linear relationship between customer value and solution complexity, i.e. your system does not reward efficiently attending to 20 high priority low complexity issues that improve customer satisfaction by 30%, vs expending the same effort on 10 medium priority and complexity issues and improving customer satisfaction by 5%.

This is why measuring velocity is only meant to calibrate what a point means to a team, estimating impact of a contributor being out for vacation, etc. Your org is running a clown show.

[-]

Mikefrommke@reddit

Managers could assign a new completely separate arbitrary number we will call “business value”. If they want to explain what was delivered in numerical terms that’s their option. But they won’t do it because that’s more work for them.

Shareholders who would be sophisticated enough to understand story points per teams but not realize it’s a games metric are few and far between. The question is how much are you spending building the product and how much is the product making.

[-]

ohnoivegivenin@reddit

Legitimately have you ever worked where these metrics are not bubbled up to execs to track team functionality?

[-]

bwainfweeze@reddit

Only in graphs that they don’t pay enough attention to to notice.

[-]

Infinite_Maximum_820@reddit

Every job I had. I read this thread and thought was satire. I’ve been on the industry for 20 years and work on big tech where we don’t even use agile

[-]

titosrevenge@reddit

If you store your points in your ticketing system then they're public regardless of whether you want them to be or not.

Regardless, the easiest way for OP to avoid this mess is to simply inflate the estimates while their QA is away. If their management team wants to play stupid games then they should expect stupid prizes.

[-]

litui@reddit

This is actually a terrible idea as it serves to rationalize reduction of team size. "Oh, the numbers didn't go down when they lost a member? Guess they didn't need that person after all."

[-]

titosrevenge@reddit

Ugh you're right. Damned if you do and damned if you don't.

[-]

czeslaw_t@reddit

you get what you measure 😏

[-]

oupablo@reddit

They're story points. They are made up and don't really mean anything. Just add a few points to all the stories.

[-]

Empanatacion@reddit

Isn't that not the case with SAFE? I may be misremembering, because it has thankfully been a while, but I thought the points were "public record" in SAFE.

[-]

freekayZekey@reddit

you are correct. points are public in safe; that is one of the mountain of reasons why safe is bad

[-]

ninetofivedev@reddit

I hear you but I’ve also found it to be a bit naive.

Management and stakeholders are going to want estimates on when something will be done.

If you can’t build those estimates off of the virtuous agile process, than what the hell is the point.

You know what trumos agile every time for me? Raw estimates with wiggle room.

Something might take a day or two days or 3 days or 5 days or 10 days.

To me, this has always been better than pretending that we’re measuring complexity with points and you absolutely should not use them as a measurement of time.

Like imagine if we told people to budget that way. Ok, so instead of tracking your income and expenses, we’re using points and they represent a theoretical earning potential. Don’t convert your real earning potential to the theoretical one. That’s bad.

FWIW, the agile manifesto never mentions using story points.

[-]

Imaginary-Ad2828@reddit

Advise that's just not reality. Never give into "executives are not comfortable with it". Well that's too bad. That's what happens when you actively move people off your team without backfill. Stick to your guns and if you say 70 then stick to it. Don't let them bully you into committing to a higher level output because at the end of the day all you're doing is extending your days when you do this.

[-]

Yamitz@reddit

In my opinion “executives are not comfortable with it” is the managers job to fix. He’s just being lazy and passing his work to the team.

[-]

showraniy@reddit

Sorry to say this feels true to me here. I've never had a manager or PM/PO say this after we've given estimates or other info.

My job is to give you the information and deliverables. Your job is to communicate that and plan out bigger interdepartmental projects based on this information. If someone came back to me and told me executives will not accept the estimate, I would say some equivalent of "ok."

Admittedly, we don't talk about velocity in this way, so the conversation would veer towards projects or features planned and what we can shuffle instead, because that's an appropriate topic for executives to give feedback about, not velocity. I think that's the bigger problem here, actually, and sorry I don't have advice other than "too bad, so sad." Executives should have absolutely no say in velocity, ever.

[-]

bobs-yer-unkl@reddit

equivalent of "ok."

I would say, "Okay, what is upper management's plan to fix this?"

[-]

Colt2205@reddit

That is called "how to talk up the chain." The responsibility is on the upper management, not the ICs.

[-]

Stargazer5781@reddit

They're an executive. They're getting paid $500k+. Their whole job is making difficult, unpleasant decisions that will supposedly lead to the greater success of the business. If they're not comfortable doing that, they shouldn't have that job. Zero sympathy there. My only job is to tell them the situation as honestly and professionally as I can.

[-]

Qinistral@reddit

They are making unpleasant decisions for greater success, they’re reducing resources and expecting the same output, that’s success to them. And unless others defend their WLB they’ll succeed.

[-]

Stargazer5781@reddit

They won't succeed because they won't get the same output. But yes, they may be able to obfuscate the connection between their actions and the negative outcome.

[-]

pydry@reddit

IMO this is pretty standard buck passing from execs to middle management onto the devs which can also be pretty be brought to a screeching halt simply by shifting all of the responsibility on to the middle managers for all of the things they're pressuring you to do.

"Look, this is a 5 not a 12 pointer isn't it?"

"We're perfectly happy with putting 5 down provided you take full responsibility for any reduction in velocity that will result from a potential overrun. Personally, I am not prepared to take this risk, but if you are happy to shoulder it...".

"No, I'm not doing that velocity is your - the team's responsibility."

"Put our number down then."

[-]

lab-gone-wrong@reddit

"We're not here to be comfortable" is something I find myself saying a lot at work

[-]

Imaginary-Ad2828@reddit

Hahahah love it 🤣

[-]

unflores@reddit

Hah, not only will it go down. But onboarding a new QA will keep it down for awhile. And you'll have a build up of ready but un-qa'd tickets which will potentially increase bugs and decrease output.

Now, one of their options is to decrease QA necessary and expect an increase in Customer reported defects.

[-]

poeir@reddit

When reality asserts itself, it wins every time.

When managers override estimates, they're discarding the expertise that they were responsible for hiring (presumably—and even if not, it's still the expertise that they're responsible for retaining). They're also wasting the time of their staff (and therefore the resources of the company) by having them do work in creating the estimates and then throwing that estimate away. This is a manager's decision leading to the the salary cost of creating that estimate leading to zero value (admittedly, there are cases where salaries get paid and create negative value, so it's not the worst possible outcome).

Anytime a manager goes "That's your estimate? Nah, let's use mine." they're doing a bad job as a manager in multiple ways.

[-]

bwainfweeze@reddit

If they keep poking I would get to the point where I say something like, “so you want me to start lying to you? Because that’s what happens when someone tells you the truth and you tell them the truth isn’t good enough.”

Middle manager is trying to cover his own ass instead of taking care of the team.

[-]

Imaginary-Ad2828@reddit

Yep, too many managers out here trying to save their own asses. My focus is always my team first. Don't care what happens to me I just need to make sure my team feels confident, feels like they have what they need to get a quality job done, and that they feel supported with their decisions, mine and the enterprise. Your team is the bedrock.

[-]

forgottenHedgehog@reddit

Even with backfill I'd expect the capacity per person to drop for a couple months compared to the original team.

[-]

Imaginary-Ad2828@reddit

Exactly this. Knowledge drain is a productivity killer especially with development. This is largely forgotten by the "decision makers" which blows my mind.

[-]

bwainfweeze@reddit

Because there’s a school of toxic management that believes in mind over matter. As if they just will things into existence.

This also falls under the umbrella of “nobody becomes a billionaire without fucking people over.” They don’t see all the charity work that people end up doing for them with no reward for themselves.

[-]

Imaginary-Ad2828@reddit

You got it. As a manager myself I am constantly fighting this type of attitude from other "leaders". I refuse to let my team get stomped on by executives that seem to think doing more with less is the way to go. Absolutely not. You want a quality product then we need x,y,z not just x.

[-]

prescod@reddit

You lost 1/3 of your testers but what percent of your total team did you lose? If your assumption is that a developer cannot in any way compensate for the loss of a QA then you are being unreasonably stubborn. Yes your points should go down but the debate you and management might be having is how crippled a development team should be by the loss of a QA. And that depends on the extent to which you change your processes to compensate.

[-]

Ok-Car-2916@reddit

This is the only good advice on this thread to be honest. If a 90 velocity is what upper management will accept, I think it's possible based on the numbers OP provided to reallocate and get pretty close to 90 without lying. If this is a one off situation and it doesn't happen again, then I'm not sure I would be on board with everybody telling OP to go find another job or make a big stink about this.

Of course ive been in situations where they do the same thing again and again and each time won't accept anything lower than 100% of what was done before, in which case yes that is a sign that the company is in trouble.

[-]

jhuang0@reddit

I'm surprised I had to scroll this far down to find this comment. The obvious solution when you have a bottleneck is to remove it. The team is developing 30 story points worth of product that can't be QA'd in time and is short 15 story points of QA. Next sprint, all you need to do is allocate 15 story points of QA to developers instead of doing the extra 30 points of development. Is it the best use of developer resources? No. Will quality probably go down in the interim? Probably. But you will have reached management's goal and the costs of this will be brushed under the covers until you replace the QA person.

[-]

Thiht@reddit

You’re dealing with unreasonable people so reasonable arguments won’t work. Higher management should not even be aware of the concept of story points, this is for internal organization. Just tell them what will be done at the end of the sprint(ie. sprint commitment), and if they’re not happy with that they can throw more people at it.

In case they want to be reasonable, explain that the throughput of a pipe is limited by its thinnest section: less testers = more things blocked in the testing stage = less things delivered. Teams need to be balanced from end to end for optimal delivery.

[-]

PhilWheat@reddit

"...and if they’re not happy with that they can throw more people at it."
Unfortunately, "Adding manpower to a late software project makes it later." - Brooke's Law.

[-]

netizen123654@reddit

If you're trying to point out how this argument could be leveled against OP in bad faith by management, then ok. But Brooks' law wouldn't seem to apply here since the additional people would be backfill rather than brand new entrants.

[-]

PhilWheat@reddit

Unfortunately, it does apply since even backfills have ramp up time and team destabilization effects.

[-]

local_eclectic@reddit

Adding more manpower to testing isn't the same as adding it to building. Testing scales much more linearly.

[-]

PhilWheat@reddit

Completely depends on your definition of QA.
Manual testing might (but I'd have some reservations even there.) Adding an SDET almost certainly won't.

[-]

ub3rh4x0rz@reddit

You can also present them with an option: "were down a tester, so either our point estimates will increase to account for the testing bottleneck, or we spend some effort now changing our test processes, including but not limited to decreasing testing, which will mean a greater defect rate, which will mean more bugfix than new feature stories in our backlog moving forward.

[-]

lunivore@reddit

It's not just the defect rate from bad code getting through. Good testers give fast feedback, while the code is still fresh in devs' heads. When that feedback slows down, devs have to context-switch more often, which leads to time being wasted shifting contexts (git checkouts, data setup, builds, etc.) and more bugs due to trying to hold more in your head.

Having said that, if you're going to change your test processes, make it increase rather than decrease quality so that less testing is required. Add automated tests wherever possible and help each other level up the clarity and maintainability of the code too. The last thing you need to do with a bottleneck is try and force stuff through it twice.

[-]

UnrulyLunch@reddit

Fast, good, or cheap. Pick two.

[-]

jezza323@reddit

Management would like all 3 please, despite their decisions. End of discussion, get to work 😔

[-]

Embarrassed_Quit_450@reddit

unreasonable people

I would have said clueless idiots but I guess this is more polite.

Higher management should not even be aware of the concept of story points, this is for internal organization. Just tell them what will be done at the end of the sprint(ie. sprint commitment), and if they’re not happy with that they can throw more people at it.

Doesn't look like they're doing agile at all.

[-]

bobs-yer-unkl@reddit

"Scaled Agile", so yes, not agile at all.

[-]

MOTIVATE_ME_23@reddit

I don't know storypoints from QA testers, but I assume/hope they reassigned the QA to a higher value project.

It's possible thatyiur immediate managers are budget constrained by other factors (like top management demanding headcount reduction across the board) and just trying to figure out how to pare it quickly, not immediately caring/considering the team dynamics and whether it was efficient.

Tell them you don't know what reason they reassigned the QA, but based on short-term loss, the best the team can do is X output rate because it is a bottleneck.

Show a team matrix of what jobs they can do and their effective task rates and time costs at each task compared to the missing QA.

Remind them that each project is different, and humans are still better at guessing efficiency and outcomes based on experience (which higher up don't have) before calculations, so AI can't work immediately. Hopefully, thus will dissuade them from trying AI with disastrous results.

Without telling them, write some code to make an educated guess about how to efficiently reassign people with the known parameters. Don't tell management about it.

Instead, create 3 or 4 possible solutions by changing one factor that will increase metrics immediately (assuming they don't cut corners by assigning mutually exclusive tasks to the same person losing integrity). Propose each of these instead with a formula they can trial options and a matrix of each team members efficiency (that they can't explicitly know) at each tasks (if you know it) and their cost per hour (if you know it).

Also include your ideal team configuration with known bottlenecks compared to the current configuration so they can understand your issue.

If any of their options work, ask to adjust output expectations until your QA returns. If they are happy with the lower output, it will stay the same.

[-]

satanfromhell@reddit

This is a sign that management is willing to compromise on quality for a bit. Explain that the only way to reach 90SP is to lower the quality threshold a little. If they are comfortable with that, then go with it. In the end, it’s their decision to make. Also, active job hunt on LinkedIn; when management lowers quality, bad things happen in the long run.

[-]

viniciusvbf@reddit

I worked under SAFe and just reading this makes my blood boil. What a nightmare that was. It's probably the worst kind of micromanagement I have ever faced, because it's not only your boss micromanaging you, it's the whole fucking company, it's multiple directors and even the CEO looking at everyone's work with a magnifying glass. But at the same time, they want to feel important and be part of the process, so we have that fucking PI Planning that sucks the time and energy of everyone to accomplish nothing more than wasting everyone's time. Anyway, I see no exit here. In your place I would just stick with what I think is right: showing them that you can't do more work with less people. It should be a simple concept to grasp, but since there's no logic to SAFe or the people who are running this hell of a company, that will backfire. If you really need to keep your job, just game the system, inflate story points, create fake stories to increase your points throughput, things like that. I GUARANTEE you that the teams you are being compared to are doing this. When a metric becomes a goal in itself it stops being a useful metric and it will be rigged, 100% of the time.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

It's my first stint with SAFe and truth be told:

If I get told that they use SAFe at my next job they better include hazard pay. Not a pleasant experience.

And I am probably less prejudiced against agile than many others I met! I actually like the concept!

[-]

johnwilkonsons@reddit

Personally I don't mind agile. SAFe is what turns it into a managerial clusterfuck.

The reason they pick SAFe over traditional agile is because management wants to be able to see and control what the teams do. And it attracts the worst kind of people into those roles if you don't watch out. I've had scrum masters who didn't listen to anybody in the team, just kept yapping all day about the theory and tooting their own horn. I've had a PM (not PO) get mad at an entire ART during an Inspect & Adapt because his graph of web services delivered per sprint went down in the last sprint of thr PI. Upon which was a lot of silence before thankfully a brave senior engineer stepped up to opine that perhaps these services were more complex, or this amount was all we needed to reach our goals. But the dumbfuck of a PM only knew his graphs and got mad because line went down.

I'm pretty happy working for a small (10-15 people) startup right now in comparison (after 5y of the above). I have 2 days a week with 0 planned meetings. The other 3 days have 1 meeting each of 60-90 minutes. It's liberating how much shit you can get done without all the overhead. The amount of office politics remains roughly the same though, interestingly.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

I've had scrum masters who didn't listen to anybody in the team, just kept yapping all day about the theory and tooting their own horn

Boy howdy do I love useful SMs :D

At this company, we've had retros where they explicitely told us NOT to complain about problems.

Where they directed the whole retro to be around the question "what is a perfect software?" or "what kind of superpower would you contribute to the team?" - despite us wanting to talk about real problems that were encountered during the sprint.

They got really angry when we ignored them and talked about our stuff, leading to very helpful meetings with management.

We've since "replaced" our retros by informal after-work-pub-sessions

[-]

johnwilkonsons@reddit

Yep, exactly these kind of shenanigans were done by our SMs as well. We'd had a really bad sprint and the guy wanted us to spend the entire retro filling in a skill matrix to find out which (soft & hard) skills we were lacking in the team.

At the start, we had to fill in our current happiness feeling, 0-10. Most scored really low, and several (myself included) objected to the darn matrix. SM plowed on anyways.

We filled in the fucking thing, and you had to basically self-asses your own skills and others could fill in whether they agreed or disagreed with your own number (not higher or lower, just agree or disagree). The fucker gave himself a 9/10 for listening and everyone disagreed lmao.

We then also had to fill in a rating for what we thought about this retro, which was mostly 1-2/10. Thank fuck that guy left shortly afterwards.

Anyway, my point is basically that when an org gets too big, you somehow have the room to hire these clowns and get away with it. This wouldn't fly at a small company because you don't have the time and money to waste on bullshit. But big corpo's, sure. And then it's all down to how well management knows how to develop software and listen to their own employees. Uh-oh.

[-]

viniciusvbf@reddit

I was honestly open minded and even optimistic about it at first. A method where the whole company was engaged with, very well defined methodologies and rituals, based on agile principals, it all sounded great. I was there when it was first implemented at the company, so we all went through weeks of training before the first PI. I guess we had the perfect conditions to make it work... except for the fact that IT CAN'T work, because it's flawed at principle. Now it all sounds so obviously stupid to me, but I had to work a few months under it to realize that.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Yeah, in the beginning it sounded like "oh neat a tight process?" - which was a welcome change after the chaos of the job before

Nowadays I kinda miss the chaos

[-]

armahillo@reddit

Do you have ZERO qa people?

Is management ok with no QA?

[-]

Exotic_eminence@reddit

This is the trend unfortunately- after fighting to get out of QA to be a dev and reaching Solutions Architect level I would happily go back to being a QA test architect

[-]

armahillo@reddit

I've seen this too. Wild.

It's like we collectively learned nothing from the whole Crowdstrike thing.

[-]

Exotic_eminence@reddit

Exactly

[-]

GamesMaxed@reddit

Increase the story points you assign to every ticket.

[-]

Sheldor5@reddit

yep, beat them at their own stupid game

[-]

spaceneenja@reddit

This is the only answer in this thread.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

mgmt keeps track (vaguely) on how we estimate stuff, that is difficult

[-]

SanityAsymptote@reddit

If they were actually keeping track of that they'd understand that the number of story points correlates with the number of people.

You can also just start splitting tickets to increase the number of points without changing your estimates.

If your stories have a point floor, you can abuse that.

[-]

pydry@reddit

if you bump up story point estimates by 1/3 how can they tell?

this is your one point of leverage against management's boot on your neck and you're refusing to use it. why?

[-]

UmUlmUndUmUlmHerum@reddit (OP)

We could do this - but they use past reference tasks to compare estimates.

No joke - it has happened that we got a mail along the lines of "this story is estimated for 8 SP while similar sounding stories in the past were 5 SP. What gives?"

Management has a fetish for comparative estimates

[-]

Narxolepsyy@reddit

Honestly shocked/impressed you get any work done with middle management doing their best to slow you down

[-]

UmUlmUndUmUlmHerum@reddit (OP)

we could be genuinely so much more efficient if we were just left to our own devices and could just do

[-]

brewfox@reddit

That’s why I do with my team. Kanban board, no bs estimates. I give real world estimates on critical tasks (15 years in tech recent manager), padded a little bit in case things go wrong (this is only about 20% of our work). If things go over the estimate, I give a good reason why along with a new estimate. We fly through tasks because we have almost no meeting overhead (30 min planning once a week and one 30 min demo call for my boss and team at the end of the week, that’s literally it for scheduled meetings.

[-]

dbgtboi@reddit

This is hilarious

I actually did this with my team as well to pump out more work

What ended up happening is that my teams metrics were so much higher than every other team in the company, that upper management thought we were cheating the metrics

I ended up having to revert all the process efficiencies we made, in order to bring things more on line with every other team

[-]

brewfox@reddit

lol, a better process helped? Nah, tear it all down so we are as slow and bloated as everyone else. I’m glad I have the power to run my team how I like.

[-]

dbgtboi@reddit

Well at first I was baffled

But now I'm thankful. We were getting through so much work we would have run out

Now the pace is so much slower which keeps our backlog neverending

Sucks for the company, but much better for the workers since nobody ends up losing their jobs due to a lack of work

[-]

brewfox@reddit

ahh. We’re understaffed with a feature list a mile long, we’ll never run out of work and I’d rather my team just work at a reasonable pace and take the rest of the time easy, rather than filling it with useless meetings to fill the day (mostly remote team)

[-]

dbgtboi@reddit

Yup

We are permanently understaffed due to huge amounts of bloat

I've joked with my team before that if you fired 80% of the company, we would get double the amount of work done, since 80% of the company doesn't do shit except make everyone else's job more difficult

[-]

pigeon768@reddit

we got a mail along the lines of "this story is estimated for 8 SP while similar sounding stories in the past were 5 SP. What gives?"

Take stock of your surroundings. Really examine your workplace environment. Is everything on fire? Does your boss have a pointy tail and carry a pitchfork? Does it smell like sulfur?

[-]

UmUlmUndUmUlmHerum@reddit (OP)

He also sits in on the prescreening of larger features where we use t-shirt sizes to roughly pregouge stuff.

"Come oooon is this really a L? cant we let this be a M if we maybe use a less pretty solution?" is a sentence he likes.

[-]

pydry@reddit

What gives is that:

* It sounds similar but is subtly different. If you have half an hour I can explain right now what the risks and issues are with this ticket...

* There were corners cut previously in an attempt to meet management's productivity targets and that technical debt doesnt just go away on its own.

* If [ manager running the estimation meeting ] thinks it is 5 story points management is perfectly entitled to overrule the devs, put down 5 as the official number provided they take responsibility for the projected overruns.

* We're a man down and this is your responsibility.

I have a fetish for manipulating management into taking public responsiblity for shit that they really want that I think is probably going to end badly.

[-]

bwainfweeze@reddit

Had a terrible boss and one day the other lead and I realized we were in a silent conspiracy to make her say the stupid things out loud in front of the entire team.

After we talked about it he referred to it as “sport”.

This was after she wasted the entire team’s time by using a ridiculous graph to make decisions and not changing the graph nor her behavior for months of weekly meetings where we spent fifteen plus minutes every meeting complaining about the garbage chart and the garbage conclusions. Yet every week she showed up not having made any of the changes we demanded.

So eventually we came loaded for bear.

[-]

bwainfweeze@reddit

Because we found regressions when we tried to do these in 5 points and those caused us to move stories into the next sprint.

You’re going to have longer QA times. That means you have to deliver the stories to them sooner. You are going to have more overhead because you’re going to have more work in progress because of this. It’s going to add a point to every story, so you’re going to have to either start cutting stories in two or rounding up the points.

[-]

drunkandy@reddit

Your executives need more to do. I can’t imagine e.g. my company’s cto even talking to me about a story.

[-]

dogo_fren@reddit

Get the fuck out of there.

[-]

ALAS_POOR_YORICK_LOL@reddit

Goddamn you need to leave that job.

But anyway, just consider it practice defending estimates. There's always some reason. Give it a bigger estimate and move on. Dont back down on your estimate because they're basically just trying to pressure you into long hours for no reason

[-]

hw999@reddit

Your boss sounds like an asshole. I'd give a best effort to convince them that velocity will go down, if they wont budget, then it's time to dust off the resume. Iveouldnt even give 2cweeks notice. if they were really being dicks about it I'd try to poach some of the team, or at least convince them all to polish their resumes as well.

Sooooo sick of rich assholes thinking they are entitled to more labor just because.

[-]

NopileosX2@reddit

Just ChatGPT an answer to those questions, give in old task and description and new one and let it generate a nice sounding text why the new one is more difficult.

Like if they get a well written technical sounding reason they can't really do a lot against it, unless they want to challenge you on a technical level, which they should lose, unless they actually have enough technical knowledge you call what you are doing.

[-]

SpudroSpaerde@reddit

I don't think you will find advice on how to deal with working in actual hell here. Have you tried prayer?

[-]

UmUlmUndUmUlmHerum@reddit (OP)

I don't think you will find advice on how to deal with working in actual hell here.

But what I am finding are the fires of VERY catharthic reassurement from all of you :D

My CV is up to date, I am in the process of leaving already. Just trying to leave the place better than before and whatnot (in case I need to stick around for longer)

[-]

babige@reddit

Man they are driving you like they stole it

[-]

Herve-M@reddit

In some system very easy, at least for the one using BI with good data and data driven pipelines.

Most easier example are support ticket like ACL, redirection, manual process trigger etc..

Otherwise simpler task like: - changing basic UI/IX stuff - deployment related stuff - inter team sync - (normal) up keeping

[-]

pydry@reddit

this is fantastical. Ive never seen a dev team with even a large minority of replicatable, cookie cutter tasks.

Changing basic UI/UX stuff is both a small part of the job and also just as much an entry point to necessary yak shaving as any other part of the job.

[-]

Herve-M@reddit

Never worked in a team or a company doing jobs like:

Updating UI/UX design system? Ultra repetitive especially in large company where internal framework are present
Auditing and updating business ACL?
Triggering special automated process? (GDPR, DPA, etc)

Never from never?

[-]

pydry@reddit

when i said the phrase "not a large minority" did you hear "never"?

[-]

Herve-M@reddit

If in your world of experience, you have seen a “minority of replicable work” possibly you never worked in a certified ISO workplace with multiple teams.

[-]

pydry@reddit

No, you're wrong about that too.

[-]

Herve-M@reddit

Just by your own word, “add 1/3 to any shouldn’t be trackable” then “it is no more than 20%”; even in this case it makes it possible ;)

[-]

pydry@reddit

That sentence sounded pretty incoherent to me, but if you're assuming that I pad the unpredictable and predictable tasks equally you'd be wrong yet again.

I pad the more unpredictable tasks more and the more predictable tasks less.

I just assumed that was basic common sense.

[-]

Herve-M@reddit

For me, when a someone perform a same task multiple time, per years, over multiple years: we can draw an avg.

That how we can know if a change in the process is making anything better or worst. (OKR/KPI speaking)

Now if suddenly it happens to take more time.. It should be seeable.

After if people start to cheat like common sense or habit and of course add Parkinson law etc.. Can’t help.

In many of my past as current company, typically roadmap are set in 40/30/30 (business, technical, innovation); technical being cross wide and always within yearly capacities of teams. Most technical topics were planned knowing how much it would consume time and ressources speaking otherwise we would have never succeeded. (even if sometime late).

Process value mapping is our core, we know what, how and when for the common part of our system. Sure we have “it depends” over legacy part but more than 70% of our teams “repetitive tasks” are done within same timing. (not including layoff oc)

[-]

pydry@reddit

For me, when a someone perform a same task multiple time, per years, over multiple years

That hypothetical person works minimum wage in a call center or flipping burgers. They don't develop software.

[-]

Herve-M@reddit

Sadly it is my main domain, companies send me to the other side of the world to understand why “their working dev center doesn’t work as before in X” (typically US or EU based moved to India or Vietnam)

Started in North America and now on missions on ASEAN for the last 8 years.

[-]

pydry@reddit

don't worry i wasn't laboring under the impression that you were an experienced dev. you gave off skeevy middle management vibes from the first comment.

[-]

bwainfweeze@reddit

The backlog in QA is going to cause more points to be assigned to stories anyway. Let the baby fall. You’re going to have to let the fuck around and find out in order to fix this.

Every time it takes them longer to find problems with the code, drop what you’re doing and go back to fix the problems. Slip stories due to lack of QA time. Take the QA people out to lunch and ask them not to work any overtime to make the numbers work.

If you guys try to give them what they want you won’t get raises for it. You’ll just work that much harder for the same pay and they will get the bonuses for having done so.

[-]

freekayZekey@reddit

i can see it not working if their company is similar to mine. unfortunately, we share our velocity and pointing average with management and a group of project managers. so they do dumb math like x points * y months = z completion date. it’s dumb, but it happens.

whenever i advocate for increasing points, i get pushback because the people outside of the team can view the numbers. jira’s a gift and a curse

[-]

pydry@reddit

the points are made up and dont matter and nobody outside of the team knows what they refer to anyway. that is all entirely by design.

they are used solely to give mamagement some illusion of control over your output. you're not responsible for making that real.

[-]

freekayZekey@reddit

oh i am aware. unfortunately, management isn’t, and my managers capitulate and play into their ignorance.

[-]

pydry@reddit

oh i am aware. unfortunately, management isn’t

in which case they aren't able to push back on story point inflation.

[-]

bwainfweeze@reddit

It’s not dumb it’s idiotic.

You can’t divide story points by velocity to get the end date when you don’t have all of the stories. Thats what agile is. You react to things as they happen and rework your priorities to deliver something, and maybe not what you initially agreed to. Then you make a new milestone and you look at what was below the line and try again.

[-]

Wrong_College1347@reddit

How can you keep track on how a group of developers estimate userstories?

[-]

UmUlmUndUmUlmHerum@reddit (OP)

He looks at our stories and looks at how similar stories were evaluated previously

[-]

Wrong_College1347@reddit

He is paid to do that? I believe it’s waste. He should do testing instead :D

[-]

UmUlmUndUmUlmHerum@reddit (OP)

paying him NOT to do anything would be a novel AND productive solution

[-]

kevin074@reddit

Increase one ticket by 1 point and you’ll hit your target close enough?

[-]

local_eclectic@reddit

Story points are usually exponential though and follow the Fibonacci sequence. I'd probably just break tasks down into smaller units and add more individual 1-2 point tickets.

[-]

Jmc_da_boss@reddit

Then break a single 2 into two 2s

This shit is easy to fake.

[-]

fragglet@reddit

So are you saying that management object to estimates and sometimes complain if they're higher than they like? Because engineers being the ones doing the estimates is another thing that's fundamental to the agile process.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

We also have customers requesting technical implementation details in one of our teams it is funny like that

(Yes, one of our managers has a bit of technical background and really likes micromanagement)

[-]

coyoteazul2@reddit

"the guy who left could have done it in 2. The remaining team has different areas of expertise, so taking new areas is going to take 4"

[-]

Rulmeq@reddit

Yes, this is what will happen, they will get 100SP every sprint, but they are going to still be getting 70-80% of the actual value

[-]

TraumaER@reddit

This was what I was going to say. The complexity of finishing a ticket has gone up now that testing is more difficult

[-]

litui@reddit

Do not do this unless you want your team to permanently decrease in size. It's bad enough they're using story points as a metric outside the team, but a reduction in story points while a member is away still serves to demonstrate that the team needs all its members.

In my experience as a middle manager, if upper management sees there was no change when removing a member that removal stands a good chance of being made permanent.

[-]

pydry@reddit

If moving slowly while delivering at a higher measured "velocity" is making everybody happy where's the problem?

The actual velocity being lowered is their concern not yours. And, if they knew how to measure actual velocity they wouldn't be asking for bullshit metrics.

[-]

litui@reddit

Short term there's no problem. You're right in the short term. In the long term, and I'm speaking from experience here, this sort of temporary team member reassignment paired with "measurement" of effect is used to rationalize future downsizing.

Management's pushback on the (very obviously legit) reduced velocity implies strongly to me that they're hoping to see it go back up without returning the missing team member. The team's direct manager in this case absolutely needs to stick up for the team and insist that velocity can't be restored until their team member is back.

[-]

Savings-Stress-7014@reddit

This is the way

[-]

melodyze@reddit

You and the testers need to explain specifically what is constaining throughput.

We need to run these tests for anytime that touches these things. Those tests take bla amount of time each. With 70 story points, that means about bla total time, divided by two people that is two weeks full work schedule for them.

Then, in order to get them to agree with the specific treatment you want, hiring someone, you have to convince them that you've already optimized that flow as much as it can be optimized, and that flow creates more business value than it costs.

We already group tickets by overlapping testing needs and staggered development work to maximize parallelism, so that neither testers is waiting for new work. Testing is already as automated as we can get away with, when we tried automating farther the automated system was shown not to be able to catch bla serious category of problem. We can't remove any more manual tests from our process because we have exactly one case covering each major category of error, and if a release breaking ever made it through, then it would cost the business so much more than the total labor costs here that we can't justify removing the work.

[-]

IAmADev_NoReallyIAm@reddit

Ok... first, who was the bone-headed manager that pulled the bs 90 number out of his ass in the first place? Because that just became a metric and as such just made it useless and unachievable. That's not how that works. The team sets their velocity, not management. My old team has a velocity of 40 points. My new one has a higher velocity. But they also have two different pointing systems. Once uses a max of 13 while the other uses a 21 point rating system. Because that's how the teams should be operating.

Management shouldn't be dictating what your velocity should be. The moment they do, it becomes a metric, and it looses all meaning.

[-]

Exotic_eminence@reddit

Man I see why QA always gets the blame and they want to just totally get rid of testers

[-]

wskttn@reddit

You’re pretty fucked unless they hire someone in a product leadership role that understands discovery and delivery pipelines. Someone who is not afraid to ruffle feathers, especially at the top.

[-]

BanaTibor@reddit

Tell them it will go down to 66 since they have created a bottleneck in your dev process. Probably will go lower as your 2 testers starts to burn out. What if they decide to go on a holiday, bumm down to 0, or one of them gets sick that would halve your QA capacity.
Three people is the bare minimum but five would be better.

[-]

beaverusiv@reddit

One of my favourite sayings "I can disappoint you now, or I can disappoint you later - you decide"

[-]

NoJudge2551@reddit

They already reallocated the budget and/or are using it as "cost cutting" for performance. If you inflate points or say yes to 90 velocity, then they don't have to hire anyone else and can say they "saved" costs there.

I'm sure the next ask will be if GitHub Co-Pilot or some other intern level AI can just "pick up the slack".

[-]

MaD__HuNGaRIaN@reddit

It is not always true. Depends on the people and the project.

[-]

PunkRockDude@reddit

Just recalibrate. What was 1 story point yesterday is now 1.25 story points. Problem solved velocity is up again.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

management sees "oh productivity is WAY up with fewer testers? lets make the situation permanent" and boom, the institution went a bit more rotten

[-]

NeuralHijacker@reddit

Not your problem. If upper management wants to trash the company by doing stupid things for a bonus, they will. Either get yourself promoted to a point where you can do something about it or quietly start looking for another job.

[-]

PunkRockDude@reddit

And it never helps to point out why the ideas are stupid. Have to show you are a team player fully vested in their vision and then it just didn’t work out due to circumstance outside of the leaders control or something.

[-]

PandaWonder01@reddit

You can't cook a roast twice as fast by using more ovens

[-]

bulbishNYC@reddit

This is like asking help from people with PhD in physics to help convince your Flat Earther neighbor.

You’re an IC. This is not part of your responsibilities. Point the finger to your engineering manager or team lead and let them deal with management stupidity. Did you ever receive a raise or a title increase to be responsible for whole team? Then just focus on delivering your IC contributions.

Second point, you seem hesitant that this is clearly stupid management problem. They are playing blame the victim game, and you are buying it. When I encounter stupid management like this I learned to quickly set my boundaries - guys I’m am not a manager in job title, I can’t advice on resourcing, only tech discussion please, I am not interested in management career path or promotions. In places with dumb management you can’t pay me enough to move away from technical career track.

[-]

08148694@reddit

I agree with your overall point that losing team members will reduce velocity

Where I disagree is with reducing velocity by 1/3rd because you’ve lost 1/3rd of your QA team

That implies that QA team is a complete bottleneck and your other engineers will be sitting idle waiting for the QA backlog to clear. This is utterly dysfunctional.

[-]

reboog711@reddit

engineers can and should be able to take on that role for their own tasks

Strong disagree. People QAing themselves is a recipe for disaster. Because they don't know their blind spots. I built it to do "X" and I tested for "X" and it works. And then someone does "Y" everything breaks.

On teams I've worked on w/o QA; another developer often takes that "Find their Blind Spot" responsibility during PR Reviews.

[-]

2_bit_tango@reddit

Devs are crap QAs. Very few scenarios are devs OK for testing. QAs immediately break things in bizarre ways that would never occur to devs to test. Then QAs sign off and Users break it within minutes in prod lol. We had one bug that users were causing constantly, every minute. Users didn’t know how they did it. Couldn’t reproduce while we were watching. it took a 15 devs, QAs, and BAs 5 hours to manage to reproduce it. Stupidly simple bug, but none of us ever opened the dialog and hit save without entering any info.

[-]

odd_socks79@reddit

I'd use the two QAs I have to focus on creating test cases and data, have the extra Dev capacity do the test execution of another developers work.

[-]

prescod@reddit

You’ve just made a strong argument that ultimately the end users end up doing most of the QA and undermined the argument that you need dedicated QA.

What you are really saying is that if a QA leaves then dev count should be reduced by a proportional amount because there is literally no way for those devs to compensate through swapping QA or increasing unit testing or fuzz testing or integration testing or browser testing.

[-]

reboog711@reddit

Devs are crap QAs.

I agree. In the area of industry I've worked in, primarily companies have moved away from having independent QA teams, though. So, we're stuck with what's left.

QAs immediately break things in bizarre ways that would never occur to devs to test.

Ideally, to combat this, there is a strong detailed list of documented requirements / conditions before the work lands on a dev, which covers edge cases. Logistically, this is rarely the case.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

although if I QA the stuff a coworker developed it would also help sharing knowledge inside the team, giving me more insight into how my coworker build stuff without needing to see code.

Splitting manual QA-Testing, PR-Reviews and Development across three people might genuinely reduce knowledge silos

[-]

reboog711@reddit

I agree, and do not think anything said is contradictory to my comment.

[-]

bwainfweeze@reddit

Out of curiosity I looked up what people are doing for story points per week. I’m mostly used to ~8 per person per week. But some of you nutbars are recommending twice that, which is just fucking stupid because nobody should be dealing with 5 different stories per week which is the sort of bullshit that can happen if you let point inflation go this high. Thats too much resolution and will lead to trouble.

For 100 story points a 3 member QA team could easily be the bottleneck. Unless you’re being dumb about points.

[-]

odd_socks79@reddit

Just because you lost one QA, doesn't mean you lose a third of your velocity, your Devs/BA pick up some of the slack, 90 is actually not that far off if you're hitting 110 now. If you take that approach, your Devs will just keep pumping out what they do now and your balance will be broken with bottlenecks.

[-]

ericclemmons@reddit

If they can’t live with it then the real problem will hopefully resolve itself 😇

[-]

jl2352@reddit

Everyone else commenting is correct when they say you should stick to your guns about reporting we have less people, therefore less capacity, and we will get less done with the current ways of working.

I would add that as a lead, it is your job to look into alternatives. If testing is a big bottleneck, can you change that? Can developers do more QA testing themselves so there is less when it gets to the QA testers? Can you drop the QA testing part entirely, and only use it on high risk areas? Or do something else.

I’d advise you privately ask yourself what else can be done to speed up development, and then try to make that work.

[-]

demoversionofme@reddit

Unfortunately times are different now and a lot of companies are doing that. Doing more with less without investing into making things maintainable is the new norm.

With the option of sticking to 70 points you most likely will hear "you are not working fast enough" (especially if they compare how teams perform) and even if you gave the right estimate it might be seen "they decided to be difficult and just do what they said will do".

However, there is a possibility that if you say ok to 90, but indicate that there is a high risk connected to a person leaving (hand overs, lack of some knowledge, etc) and let's say deliver 70-75 points it can be seen as "oh well, they tried". Performance takes a hit due to the obvious reason 🤷‍♂️. You can also say "maybe the truth is in between and time will tell, but given the circumstances let's see who's estimate was right"

[-]

Roshi_IsHere@reddit

They pulled some bs number out of their ass. Hit them with facts. 1/3rd the QA means tickets take 33% longer on average to get through testing. If not even longer because now QA tasks that were divided out are now funneling into the others. Or potentially devs that aren't experienced QAs are now getting QA tasks and turns out it actually requires a lot of time and effort to do it correctly. Circling back if you cut 33% of QA dropping down to 70 makes sense and actually is pretty decent. Assuming each QA tests 45 tickets worth of points dropping from 120 to 70 is decent.

[-]

prescod@reddit

Where did the number 120 come from? The number is 100 to 70.

If losing 1/3 of QA reduces velocity by roughly 1/3 then you are essentially pushing management to eliminate 1/3 of developers who supposedly will now be just twiddling their thumbs.

This is going to be unpopular but what management is asking is for a plan that shows how dev will somewhat compensate for the loss of the QA either by doing shifts of testing or by spending extra effort on automated tests, rather than twiddling their thumbs. Some compromises here seems reasonable given how many teams deliver products with literally 0 QA staff.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

This is going to be unpopular but what management is asking is for a plan that shows how dev will somewhat compensate for the loss of the QA

Fair point!

But: If so, they could have said so directly! And clear and good communication is something I expect from leadership.

I do agree that this incoming "we build more features than can be tested" situation is not good. The entire situation isnt.

Shifting tests partially towards dev is definitely something I will be suggesting (if only because it actually adresses the problem - if not perfectly -vs fudging our estimation numbers)

[-]

prescod@reddit

Another alternative is to give the “extra” developers points that do not need QA. Beefing up testing. Internal tools. Monitoring and ones ability dashboards. Things that build future velocity.

[-]

mistyskies123@reddit

This is not helpful for you (apols!) but the facetious part of me really wants me to ask them if they'd prefer to cut the quality testing to ensure the velocity metric is acceptable to the exec team.

[-]

relevant_tangent@reddit

Are you guys ... Working?

Yes sir, Mr. Simpson!

Could you, um, work any faster than this?

Sure thing, boss!

[-]

rogueeyes@reddit

They don't understand what story points actually mean. Anytime a team changes story points and velocity will have to be rebaselined. Most SAFe projects also align story points between teams and use it as a metric and align it with time. There is a loose (very loose) coupling with time and story points but story points are an estimate of complexity.

8 hours != 1 SP A developer can be estimated at 15 points a sprint but that's an estimate and the team will baseline to that.

It's an argument that is useless to make though. At least you're not paying contractors for the amount of story points they complete ... And the contractors are the ones coming up with the story points.

[-]

Organic-Interest4467@reddit

Make higher estimates for story. Problem solved.

[-]

kyle787@reddit

Ask them if they would be comfortable with a number lower than 75. Because if they are going to push it, you will probably end up losing team members one way or another.

[-]

przemo_li@reddit

I love story b9ards for it. You just show pileup.

(And sometimes split collumn to exactly pin point problematic step, or merge to cut on fluff reporting)

Also: have you considered asking other QA people for ad hoc work?

Also2: have you considered cross testing of less important stuff by devs? If you can get 85 SPs vs 75 that way it's good move and extra pressure point on leadership (we lack cheap QA so much, reassigning expensive Devs let us do more)

[-]

Rumicon@reddit

First thing you have to do is figure out whether this pressure is real, meaning your boss has tried to manage their expectations and failed, or whether he’s just opting not to do that because he thinks it’s easier to squeeze your team for more output.

If it’s the first one you have a larger culture problem that can’t be fixed, either move teams or move companies. Second one you need to create a situation where he would prefer to manage leadership’s expectations and usually the only way to do that is to remove the option of not doing that by going around them.

[-]

empty-alt@reddit

First off it seems management has a misunderstanding of what story points are. If they are an agile org, then they should understand story points aren't a productivity metric, they are a planning tool. Story points will never be the same across the org because each team should have their own definition of what story point means that best fits their needs, since they are the ones using them to plan sprints. Also, you are the expert in the room, it's your job to push back in a way that's politically savvy and they can understand. If they are a company that is worth sticking with, they will listen to their domain expert. If they just want to swing their you know what around instead, then it might be time to look for a new place.

[-]

Violinist_Particular@reddit

You need to pass the buck back to your manager. It's his problem, not yours, but his management will make things hell for the team if he isn't competent enough to resolve it.

Have a one-to-one with him. Ask him for some context around what he said. Ask him for some ideas on how to achieve the efficiency improvements he is asking for. Come to the meeting with some suggestions but also firmly tell him that they won't make up for the loss of one engineer.

[-]

vbullinger@reddit

Why is one third of your testers delivering one fourth of the team's output?

[-]

UmUlmUndUmUlmHerum@reddit (OP)

because we do not count "ready to test" storypoints as delivered, management ignores these.

Only storypoints that went through both QA and Dev count for them

[-]

vbullinger@reddit

So the whole team gets backed up in perpetuity?

You realize this makes no sense, right?

If it’s a team of… eight? A QA person should account for at most an eighth….

Other people in the team - PM, BA - should have to pick up the testing slack. Just saying “I guess a third of the testing doesn’t get done” is unacceptable and you guys either need to have non programmers do a little testing, get shutter QA person or be allowed to let some stories go out untested. Obviously, another QA person is the best option.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

Currently it would look like this:

~100 SP go from Dev to Test

~70 SP go from Test to delivered (usually ~100 but the missing tester impacts this)

the 70 SP is all that matters for our Velocity, so yes, we will be bottlenecked until we get more ressources.

Shifting resources from Dev to Test could work but will not fully replace a dedicated tester since we also need "our" time/SPs.

[-]

OctopusHugss@reddit

Send them a link to the repo and tell them to chip in, or to live with the reality of the situation haha

Honestly it’s a big red flag IMO. You mentioned semi-starting the job hunt, but I would do it in earnest, especially while you’re still employed. Upper management seems fundamentally flawed and that doesn’t seem like something that will change, so I wouldn’t waste your time trying to communicate to them but that’s just me haha

[-]

audentis@reddit

If it supports your case, run a query in Jira/DevOps to see how many of your story points were delivered by the reassigned tester in previous sprints. That quantifies the impact of missing the tester, and hopefully helps motivate the new estimate.

[-]

loumf@reddit

Tell them that to get more points you need to cancel 30% of the recurring meetings.

[-]

reshef@reddit

“I wasn’t comfortable losing a QA person. We all have to go through periods of discomfort. If the ask is for people to work additional unpaid hours, I’d like you to put it in writing so we can discuss it later when you’re uncomfortable with the level of unexpected attrition.”

[-]

NoCoolNameMatt@reddit

If my recent experience is any guide, you're going to have to politely prove that they're wrong in the company of their peers or higher. It sucks, but you're being railroaded. They're trying to cast their problems - their jobs - onto you.

[-]

Dziadzios@reddit

Just dgaf. It's not your business, team underdelivery is their problem, not yours.

[-]

DigThatData@reddit

You could demonstrate a simulation of a simple single-queue-multiple-servers process and demonstrate empirically via numerical simulation how reducing the number of servers from three to two impacts the throughput of the queue.

Analytically: you're already being generous. Assuming your queue was already efficient (i.e. your QA people were kept busy), the expected velocity after changing it from three servers to two would be 67SP. So tell them if they don't like 75SP, you were being generous already and the reality of the impact to your team is probably even worse than you previously articulated.

[-]

m4bwav@reddit

The stories will take longer so it doesn't seem wrong to increase the story point value of some of the tasks.

The other alternative is to just test less and release more bugging code. Society in general doesn't seem to care about software bugs as much any more, though, of courses in some situations there can be disastrous results.

[-]

mothzilla@reddit

On friday we had the last of several meetings where our boss was telling us that "70" is not a number higher management can live with.

Management should not be looking at your velocity numbers. Velocity is just there to help your retrospective discussions between developers. If they don't accept "70" then you can just double your story point estimates.

I'd suggest you switch to "T-Shirt" sizes or some other non-numerical to counter the myopic "but 70 is less than 90!"

I'd also suggest that you disconnect your developer cycle from your QA cycle. Once code is peer reviewed and merged to a shared branch (with automated tests passing) then developers can claim it as "done". The QA team can then pick if/how/when they work from that branch, and so work at their own pace.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

I'd also suggest that you disconnect your developer cycle from your QA cycle. Once code is peer reviewed and merged to a shared branch (with automated tests passing) then developers can claim it as "done". The QA team can then pick if/how/when they work from that branch, and so work at their own pace.

I genuinely want that. I have suggested so before.

This almost lead to a mutiny by several people because apparently our current QA-infrastructure absolutely cannot handle this.

Management is also too afraid of untested features floating around in main to OK this.

[-]

mothzilla@reddit

Management is also too afraid of untested features floating around in main to OK this.

But that's fine, it isn't released. main represents shared dev code that has not yet been through QA but has passed some review and automated testing. QA make their own branch (or tag) and they decide what is released/deployed.

[-]

MrMichaelJames@reddit

You lowered your estimate, thereby forcing yourselves to have a lower velocity. Did you happen to see what would happen if you tried for the same velocity or did you just give up and assume it would be lower.

Less people doesn't always lead to lower velocity, it could actually increase velocity if the one that leaves was dragging things down. But without running for a few sprints you have no way of knowing.

If I were managing your team I would not have allowed the estimate to be lowered without data backing it up. Basically your team gave up before even trying.

[-]

carsncode@reddit

Hey OP, your manager found your post.

it could actually increase velocity if the one that leaves was dragging things down

True in the abstract, absolutely no evidence it has any relevance to this situation.

If I were managing your team I would not have allowed the estimate to be lowered without data backing it up.

They have the data, it's past velocity before the staffing change. If the person leaving participated in delivering any of the work in past sprints (as recorded on the tickets), there's a reasonable expectation that the estimate for future velocity would be lower. You recognize that it's an estimate, you called it an estimate yourself, how do you not understand what an estimate is? Based on the available information they're making an educated approximately of the value they'll measure in the future. That's the definition of an estimate.

If you were a manager and "didn't allow the estimate to be lowered", you'd be living proof of the old adage that people don't quit bad jobs, they quit bad managers (as OP is working on now). That kind of power-tripping micro-management bullshit doesn't improve quality or performance or value.

[-]

MrMichaelJames@reddit

They have one data point. What velocity was before. They have nothing else except guesses. Velocity isn’t a guess it what actually happens. So without doing you have no velocity.

Funny thing with IC throwing the old “micro management” clause out there. It’s not that, it’s called managing your team to do better and not just give up when you have some negative news.

[-]

carsncode@reddit

Velocity isn’t a guess it what actually happens. So without doing you have no velocity.

Correct. You have an estimate of the change in velocity, which is what OP called it, and what you called it, until you tried to backpedal.

Funny thing with IC throwing the old “micro management” clause out there. It’s not that, it’s called managing your team to do better and not just give up when you have some negative news.

Funny thing is you assuming I'm an IC. Better luck next time. Managing your team to do better is a managers job. "Not allowing" them to inform the business as estimates change is not. In fact, it should be the manager informing the business that velocity is likely to change with a change in staffing; there's no reason a team member should have to. There's also no evidence of anyone "giving up" - this reaction is another clear indicator you shouldn't be in a leadership role. It's an estimate, based on new information. I feel bad for anyone who'd ever have to report to you if you think this qualifies as leadership.

[-]

MrMichaelJames@reddit

Seeing the whole picture is what makes a manager good. Sometimes the ICs are wrong. Knowing that is important. We are running a business not a day care.

[-]

Brilliant-8148@reddit

You are a ____wit. Did you even read the post? They lost a THIRD of their testers.

Thinking that that might not affect velocity is some mba silliness

[-]

GaTechThomas@reddit

Don't try to create metrics that support your situation. Instead, use metrics to show the reality of the situation. Read the Accelerate book, and have management read it as well (or find a Nicole Forsgren video for them to watch). Look back at the DORA key metrics. You will certainly see changes in the metrics trends shortly after the personnel change. Management has to make a choice: Which key metrics do you care about? The key metrics are: - Deployment frequency - Lead time for changes - Change failure rate - Mean time to recovery - Reliability

The key metrics must be viewed as a whole in order to see the tradeoffs in action.

Or, just play their game and redefine the story point value. The fact that story points are being used this way is a clear indicator that they don't care about reality, so renormalize to 100 points per iteration, or 1000 if that makes then happy Though that won't fool the key metrics.

On a different perspective, why was management ok with 100 points before they fired people? Given the current expectation, they should have expected 120 or more points before the firings.

If they continue with the demands, they need to know that something has to give. The key metrics WILL shift. When they do, it's usually a snowball effect - problems create more problems. Tech debt acceues interest.

[-]

El_Gato_Gigante@reddit

Expecting velocity to stay consistent after layoffs is classic corporate bs. You could try making a management-friendly presentation with graphs and pictures, but realistically they're just going to demand you work harder.

[-]

Xaxathylox@reddit

Ive seen several people who detract from the team's velocity, so sometimes kicking them off the island will increase velocity, not reduce it.

...like, i can only tell you so many times how to handle merge conflicts, Dan. At some point you need to reevaluate your career. 🙄

[-]

Delicious_Spot_3778@reddit

Find a company that is not agile based. Seriously, it’s a flawed belief system. And you won’t convince management because they think they are right.

[-]

nderflow@reddit

"If you cannot accept less work getting done per sprint, then assign the resources necessary for the amount of work you need done"

[-]

midcap17@reddit

Tell them you are very happy that upper management finds the situation just as unacceptable as you do and that you are looking forward to them fixing it by giving you back your tester.

[-]

ChallengeDiaper@reddit

What’s the average storypoint/QA delivered? You lost 1 QA, I would expect your total to decrease by that.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

pretty much between 30-35

since every storypoint needs to go through both Dev and QA the three QAs shared their load pretty evenly.

In our lived experience this was pretty much the case

[-]

ChallengeDiaper@reddit

30-35 across all QA then not per QA. Correct? I’d expect approximately a 10 pt drop in velocity for each lost QA.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

oh no sorry it is ~100 for all of our QA in the team, I was misreading this as you asking for the "QA-throughput per person"

[-]

ChallengeDiaper@reddit

I was but you mentioned the whole team was 100 so, so 3 QA would be 90 of that 100 which doesn’t make sense to me.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

To fully count as delivered a SP needs to go through 2 gates:

Dev and QA.

So unless one unit of capacity from both Dev and QA gets spent on a story it is not delivered.

This leads to the mentioned artifact - without any measures we'd end up at ~70ish points of fully delivered story points and ~30ish points of untested but fully developed stories

(but those don't count for our velocity)

[-]

kagato87@reddit

Based on OP'S numbers sounds to me like QA productivity is way up!

[-]

Empty_Geologist9645@reddit

If you make it work they will keep removing people . They don’t care how you do it. They just lay off people to get their bonuses and expect someone to figure out or pick up the slack.

[-]

Fun-Dragonfly-4166@reddit

if there was magic (I don't think there is) but if there was, then why would I share it with you? I would be busy using magic to enrich myself.

[-]

bwainfweeze@reddit

“If your ideas were any good, you’d have to shove them down people’s throats.”

[-]

Fun-Dragonfly-4166@reddit

You are entirely correct, but more importantly my ideas are not any good.

[-]

Drayenn@reddit

Like.. do you guys not have bad sprints even with full staff? My laat sprint we did 35 points, the one previous to that was 50. We had just severely underestimated some stories.. it happens.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

surprisingly things have been going OK!

We underestimated some, overestimated others and overall we were more or less on the money. The errors have been cancelling themselves out pretty much

[-]

Ab_Initio_416@reddit

Find evidence to support your position. Give your OP to ChatGPT as a prompt. It will usually list several studies. Check that they exist and review the abstract to ensure they were included correctly. Give the studies to management.

[-]

Mutant-AI@reddit

Just estimate every story as 30% more points and boom you’re even doing 91!

[-]

SmokingPuffin@reddit

Here? On friday we had the last of several meetings where our boss was telling us that "70" is not a number higher management can live with. (They hinted towards "90" being the smallest number they accept)

How would you navigate this whole mess?

People are naturally kinda looking towards me as a more experienced member in the team but I got no idea how to productively solve this. I'm just a kinda annoyed IC :D

This is not your problem. You navigate the situation by working normally. Addressing the expectations of upper management is your manager's problem.

Indicate as such to your juniors.

[-]

hitanthrope@reddit

There are a lot of "wrong" things going on here. People have already spoken about using story point / velocity in the way you are doing. I hear that this is not your fault but it does seem to be your problem.

More or less though, you can forget all that. Your message is simpler. "Team capacity has been reduced by X% so you can expect output to be reduced by X%". If you are going to have these kinds of conversations, I would recommend just saying it like that, without all the story points / velocity muddling the issue.

The flip side here is that you said it was likely for a few months, which is very little in software development time.

Personally, if it were me, I would probably tell the manager, "We will do what we can to maintain the output but you need to recognise that we have lost a team member and that may, and probably will have an effect on what we can get finished".

That is a very very easy message to send, without the need to get into all this agile stuff, which, regardless of whether or not it is a practice in SAFe is questionable these days in all contexts. What began as a way for teams to make predictions about future delivery with a bit better accuracy than guesswork, has now become the way organisations do their entire planning activities. It's going to lead to messes regardless.

[-]

JaneGoodallVS@reddit

I'd consider fluffing estimates.

Ideally you'd refactor the code base to be more testable so that devs can do testing but that's a long term solution.

[-]

powdertaker@reddit

Hand him a copy of The Mythical Man Month.

[-]

brewfox@reddit

What would happen if you just said, “no”? Would they fire your whole team? What if you said “we’re not doing story point estimates anymore because management abuses them” and link them to how It’s “supposed” to work in agile.

If you get fired, you get unemployment while you look for new work. Or just quiet quit and look the whole time at work.

[-]

pinkwar@reddit

Update your estimations. Sounds like an easy fix.

[-]

pm_me_ur_happy_traiI@reddit

Point your tickets higher

[-]

kagato87@reddit

When that is brought up, a senior ("untouchable") resource needs to chime in. "One of our critical resources was taken away. As we are running 75% productivity with 66% QA resources, I'd argue our numbers are actually up. If you like, I can re-submit the request to replace the lost member to get us back up there."

Office politics, especially with some fresh mba with no real industry experience, is the worst.

[-]

flerchin@reddit

You just do your job and when the tickets pile up in QA then they see.

[-]

thatVisitingHasher@reddit

I think you have poor leadership. In this case, I'm talking about your direct manager. You have a bottleneck that is detrimental to the team. They don't understand that everyone needs to take care of QA moving forward.

Why aren't you talking about deliverables and value? The way you report now, you could deliver 100 points of junk. On top of that, instead of defending y'all, your manager is passing the blame for what is their responsibility.

It sounds like your manager has done nothing and is out of ideas since you lost your QA. All of your issues are due to your manager not acting like a leader.

[-]

ub3rh4x0rz@reddit

The manager clearly does not have control here, it's a bit disingenuous and reductive to blame this level of organizational disfunction on the direct manager.

[-]

thatVisitingHasher@reddit

I’m sure it’s organizational dysfunction that is common among most non-technical companies. The idea that you can judge a team’s performance by story points is ignorance at best. It seems like the OP’s organization thinks it’s a good practice. At this point, the outputs vs. outcomes conversation is 7-10 years ol.

[-]

ub3rh4x0rz@reddit

Yeah, there's already been an implicit decision that points are political. You have to figure out how to end this dispute in a way that yields an acceptable narrative to the top brass and acceptable work expectations for the contributors. Classic instance of productivity theater hurting actual productivity.

[-]

java_dev_throwaway@reddit

Just point stories higher, if the execs don't understand that less people means less velocity, then they certainly have no idea how software development works anyway. Story points are monopoly money, so give them a raise and pay yourself on the back.

[-]

Irish_and_idiotic@reddit

Pad the estimates until 90 is the new 70 everyone will feel like they won and you can job hunt in peace

[-]

guywithbadopinions4@reddit

You lost a third of you of your testers, but that doesn’t mean you have to lose a third of your capacity. I think your only option is to look at the ways you set tasks and expectations between QA and Developers to take some load off the QA folks.

Ask your QA lead if developers are testing their changes locally enough before releasing or if they are leaning on QA team too much to catch obvious bugs.

Ask if there is an opportunity for automation of common regression testing workflows that developers can potentially help write, that could improve testing capacity.

You may not be able to reach 90 point capacity but you may be able to prevent such a steep capacity drop without sacrificing quality.

[-]

grumblefap@reddit

Ah, the good ole “beatings will continue until morale improves” and “do more with less” mgmt style.

They’ll have to live with the number until they backfill and you train the backfill because “a warm body” doesn’t immediately contribute to velocity. Since their “reorg idea” disrupted your team, it’s naturally going to disrupt your velocity.

I used to have a 10x mindset and a more experienced dev on my team just told me “it’ll get done when it gets done”. I’ve moved companies but that’s stuck with me ever since.

First order of business is to stop over delivering. Clearly mgmt doesn’t care and could even be why they cut someone because it triggered some spreadsheet rule or chart graph at their weekly circlejerk.

As someone who went through three reorgs last year thanks to rotating directors and each of their “new visions” I’m just fully jaded and done slaving away for them. Just continue to do your job with your logical velocity. It’s hard to argue with logic and they will try and that’s their problem not yours.

You’ve done their job by estimating your own velocity, and hopefully with metrics. Show them the burn down charts or velocity graphs and then take out one member and pretty chart goes down. They might understand that more.

[-]

diablo1128@reddit

If management wants to be reasonable then you have the conversation about why expectations should be lower. Now, is it too low? We have no idea, but you'll figure that out over the next few sprints if you over or under shot your new velocity.

If management wants to be unreasonable then there is nothing you can say to convince them. Still say your stance and make sure it's on record that you disagree with the expected velocity. Then just let things fail when you don't reach the 90 points of velocity.

When they ask why you point back to the concerns you had that they didn't want to listen to. Don't work overtime to meet the new velocity as that would just prove management right in their mind. Work normally and let the pieces fall as they may.

[-]

Patient_Ganache_1631@reddit

If it's organized in such a way that you can't inflate the story points, maybe you can do corporate bullshit jujitsu...

Figure out some kind of way to explain that they're fabulous metric tracking has allowed them inside into the team that is very telling. Namely that the bottleneck due to less QA is causing the throughput to suffer.

Then make up your own metric to show the dollar value of every story point completed. Is 25 story points less in throughput equal to the cost of a QA?

[-]

PVJakeC@reddit

Manager must have read this book, going to expect you to fix the now bottleneck through other means. - https://www.amazon.com/Bottleneck-Rules-More-Working-Harder-ebook/dp/B07DCFR7B4/ref=mp_s_a_1_1?adgrpid=161363125122&dib=eyJ2IjoiMSJ9.bOdpPlsVF6nS9oeII9XEo_-JuReisipZ9EC2mUBv9ZDnhmNkWlv7aD9RQw0iDD9C68zNPQAO3ZCW397urGIlctarpc7c6XShgYF2Slg_f2Yp_ea_rf-rHb3emN0kHIP7dJyQbh5egr4OwYt_ppTTcA.ZaOf-PqB-nROJBHyFH3wN2Q62H_ZeJLccR04FZQD5Ao&dib_tag=se&hvadid=693104114634&hvdev=m&hvexpln=68&hvlocphy=9015099&hvnetw=g&hvocijid=16735461486522406452--&hvqmt=e&hvrand=16735461486522406452&hvtargid=kwd-486686029679&hydadcr=12119_13480300&keywords=the+bottleneck+rules&mcid=d9822371fc5c3759ae2960e633f4f573&qid=1745764291&sr=8-1

[-]

Cool-Importance6004@reddit

Amazon Price History:

The Bottleneck Rules: The Go-To Guide to Eli Goldratt's Theory of Constraints (TOC) and his Business Novel ‘The Goal’ (Theory of Constraints Simplified) * Rating: ★★★★☆ 4.6

Current price: $4.99
Lowest price: $4.99
Highest price: $6.99
Average price: $5.08

Month	Low	High	Chart
04-2024	$4.99	$4.99	██████████
03-2024	$4.99	$4.99	██████████
02-2024	$4.99	$4.99	██████████
01-2024	$4.99	$4.99	██████████
12-2023	$4.99	$4.99	██████████
11-2023	$4.99	$4.99	██████████
10-2023	$4.99	$4.99	██████████
08-2023	$4.99	$4.99	██████████
01-2023	$4.99	$4.99	██████████
10-2022	$4.99	$4.99	██████████
09-2022	$4.99	$4.99	██████████
06-2022	$4.99	$4.99	██████████

Source: GOSH Price Tracker

^(Bleep bleep boop. I am a bot here to serve by providing helpful price history data on products. I am not affiliated with Amazon. Upvote if this was helpful. PM to report issues or to opt-out.)

[-]

Pentanubis@reddit

Agile is for developers to convey expectations to management, not the other way around. The whole arrangement you are facing is completely broken.

[-]

Sensitive-Ear-3896@reddit

Can you explain to them that they made a tacit choice on the good fast cheap triangle. Also as gently and non threateningly as you can, can you find out if your qa moved because the qa wanted to move?

[-]

dacracot@reddit

100% this. Sounds like your triangle was balanced but has been disrupted. Explain it in these terms.

[-]

Sensitive-Ear-3896@reddit

Although my meme self would try to work the conjoined triangles of quality from Silicone Valley into the discussion

[-]

Rhymer74@reddit

Devalue story points. Everyone’s happy.

[-]

kifbkrdb@reddit

I'm going to get downvoted for this, but if I were your manager, I'd think you're trying it on too.

A 38% drop (from 110 to 75) in work completed from a single person leaving - out of a team of at least 6 (you presumably have at least 3 devs to match 3 people in QA)? Really? Devs should be able to pick up QA work and while they won't be as fast, they won't be that slow.

[-]

UmUlmUndUmUlmHerum@reddit (OP)

fwiw we're talking about estimates as of now - so a 25% drop due to a 33% reduction is test capacity. (100->75)

Effectively we'd be talking about 110 dropping to ~80. (best case)

I do agree that capacity-shifting in the team is a good way to go - but they are effectively expecting that a 1/3 decrease in one resource can only lead to a 10% slower throughput.

Is that really justifiable?

[-]

draeden11@reddit

Present them copies of The Mythical Man Month.

[-]

reboog711@reddit

Doesn't that say, in essence, that adding more people will decrease velocity?

[-]

draeden11@reddit

I contains a reminder that adding 8 more mothers won’t make the baby come out in one month. More generally it talks about the fact that changes to team structure have non intuitive impacts.

[-]

babige@reddit

Do the most critical 50sp with standard QA and 40 with 'expedited' QA

[-]

UmUlmUndUmUlmHerum@reddit (OP)

That might actually be a decent idea? mark 50 points worth of stories as "safe" and the rest as "risk comittment" where we do NOT stand behind full functionality.

Any resulting bugs we'll try to pin on our manager.

[-]

ALAS_POOR_YORICK_LOL@reddit

That will end poorly.

Just defend your estimates man, they won't kill you

[-]

ub3rh4x0rz@reddit

I can almost guarantee this is what the top brass are expecting, except they want you to downplay the reliability decrease and generally not talk about how it resulted from their decision to drop a role.

[-]

red48-@reddit

I thought in agile you’re supposed to estimate based on past outcomes. You do a sprint and see how many points got done. Adjust the estimate for next sprint. You don’t actually know until you do a few sprints. That’s what I remember from XP or Manifesto books.

Going down from 3 to 2 QA increases variance. Say one of them goes on 1-2 week vacation and the second one gets sick.

[-]

bobaduk@reddit

In some ways it's good that management take a .interest in how you estimate, at least they're trying to base their understanding on reality..if you could just pad the estimates that would be more dysfunctional, though locally much easier for you personally.

I would write an email. I would explain that:

The composition of the team was previously in balance.
The loss of a tester means that work will pile up in QA.
That the team can aim for higher than 75 points, but it's a forecast, not a negotiating position: it doesn't help to be angry with the weatherman if it rains on a weekend.

They have four options to solve the reduced velocity:

They can backfill the headcount, and the new tester will take some time to onboard and become productive.
They can ignore the problem, and QA will remain a bottleneck forever.
They can share the burden of testing amongst engineers, which will reduce the amount of software that gets written.
They can invest time into automation and observability to reduce the effort of testing,.which will temporarily reduce throughput for potential future improvements.

You are willing to discuss the merits of any of the four options,.or to consider alternatives, but there are fewer people to do the same amount of work, and something has to give.

Good luck friend! This sounds stupid.

[-]

Cernuto@reddit

Bring management in to assist with Q/A. Certainly, with those MBA's, they can follow a test script? May cut into their extended lunch breaks, but we all have to wear many hats in the company's time of need.

[-]

reboog711@reddit

How would you navigate this whole mess?

Increase ticket pointing to acount for the discrepency. A 1 is now a 2; a 2 is now a 3; a 3 is now a 5...

[-]

lil_miguelito@reddit

Why is everyone making this so complicated. Inflate your point estimates per story by 20%.

Some 1s become 2s. Some 2s become 3s. Some 3s magically become 5s. 75 becomes 90.

[-]

Any_Masterpiece9385@reddit

Story points are made up nonsense.

[-]

PreparationAdvanced9@reddit

Would establish in writing the pitfalls of being this aggressive - promises not kept, more bugs in prod, burn out of devs etc. let them know you have no issues using 90 as long as they understand and accept the cons of their number. And then if they say ok, roll with it

[-]

Wrong_College1347@reddit

Multiply the estimated Storypoints by 100/70 and deliver 100 Storypoints.

[-]

ValentineBlacker@reddit

What are they gonna do, fire people and hope that makes the number go up?

Hm, I shouldn't joke about it, they probably would.

[-]

jcradio@reddit

Ahhh, yes. One of the many ways SAFe is garbage. Using a team metric at a higher level. Unfortunately, am organization like this does not understand Agile engineering practice and does not care how to actually be Agile.

[-]

sunny_tomato_farm@reddit

This sounds like the aerospace and defense industry. lol.

[-]

haroldjaap@reddit

If testers are removed and similar velocity is required, the quality goes down as testers will less thoroughly test stuff, thus finding less issues thus developers having more time to implement new features (albeit buggy). I don't see how you can't just say velocity can stay the same (or even go up) but quality will deteriorate.

Management will have to make a choice on this, can't just prune valuable employees and expect no change.

If however they only removed underperformers you might be fine.

[-]

freekayZekey@reddit

sorry, but i do not believe you will get any particularly good advice other than “stick to your guns” and “sharing your velocity is a bad idea”, and i can’t blame people. we don’t know your company’s culture, management’s personality, etc.

unfortunately, you’re dealing with a simple minded person who thinks they can just will people to bump velocity. i don’t know how to solve that besides leaving

[-]

Revision2000@reddit

Internal reorg has led to one of our team-QA-people to be reassigned elsewhere

Which you didn’t ask for and was beyond your control.

This then has lead to us reducing our velocity-estimate to 75SP - we lost 1/3 of our testers so it naturally goes down.

A natural consequence as this is within your control.

"70" is not a number higher management can live with

It’s in their control to assign a new QA person. So tell your manager you’ve lost a QA person, which naturally means lower velocity, so they should assign a new QA if they want higher velocity.

they have a hardon for storypoints to be similar across teams

Lol.

My team would estimate on a logarithmic scale or just assign 0 SP if they’d start pulling that shit here. Comparing velocity across teams is not what SP are meant for 🤦🏻‍♂️

[-]

fletku_mato@reddit

Story points are imaginary anyways, just reduce the imaginary value of a single story point and be done with it.

[-]

angrynoah@reddit

As soon as you add them together, you are breaking the contract of story points (a major reason story points are bad and should never be used). You are using a non-scalar thing as a measurement tool. That simply does not work.

You have management that believes obviously false things and forces you to work under methodologies that are known to not function (SAFe). You can't win.

[-]

CXgamer@reddit

Ask them what their budget is so you can hire QA.
Propose to redefine story points to meer their arbitrary goal.
Ask them for a budget for overtime pay, if new hires aren't possible.

But in reality, this is just management that's pushing. They always do this. It makes some people feel guilty and do extra work for free. I'm no expert in social optics, but I think you can also just ignore this.

[-]

Vfn@reddit

Showcase the bottleneck? If it's fewer QA people you would see more items stuck in QA for longer. If you're already communicating this, the business may be trying to squeeze the current engineers to an unreasonable level (assuming engineering is already pulling its weight).

Truth be told, I've never had to explain that fewer people would result in less work. It's always been much harder to explain why adding more resources is not linearly scaling more work.

[-]

forgottenHedgehog@reddit

You keep telling exactly that, there is no magic. I don't know what the structure of your team is, but including non-testers into testing is also an option (might help if QA is a bottleneck).

[-]

WJMazepas@reddit

Well, you can always just inflate the story points so it reaches 90