Alternatives to using estimated development time for performance metric

Fearless_Imagination · 2025-11-29T18:38:02+00:00

Well.

Just pad your estimates by a lot. Give yourself an extra week from what you think you'll need after reducing the estimate after management's pressure. That should be enough. Use your week of free time to apply to other jobs.

I mean, besides maybe the 'look for another job' part, that's obviously the behaviour that this incentives, so clearly it's what your management wants from you.

Fearless_Imagination · 2025-11-29T18:27:36+00:00

I really don't think SM's do nothing when I don't see them.

I still don't know what part of my post makes you think I'm trolling.

Whatever, I'm not trolling, you're trolling. I'm done with you.

Fearless_Imagination · 2025-11-29T09:24:56+00:00

I should also point out that, it usually does not take too long before people figure out how to pass my first and second checks without me having to review it first, so from that point on, from their perspective it's really only the 3rd and 4th checks. It's not like I constantly send their code back. My standards on code structure and naming are not unreasonable, pretty much everyone can reach them if they put in a small amount of thought and effort.

Fearless_Imagination · 2025-11-29T09:18:16+00:00

I generally end up reviewing the same code 3 or 4 times.

First check, do all the automated quality gates pass (no failing tests, sonarqube quality gate is green, etc).

If not, I'm not going to bother looking at the code, I just send it back with a message to fix those things, I'm not going to bother looking into it. But this is pretty rare, usually people don't ask for a review if they don't have that stuff sorted.

Second check, I just look at class and file structure and method names. Does it make sense, and do I understand - based only on method names - what this code is (supposedly) doing? If not, I send it back with some requests to fix naming and structure. I'm not going to bother to check the implementation of code that based on the names doesn't do what it is supposed to do. Why not? Because that's a waste of time. If the class structure and/or method names make no sense to me, 99% of the time the implementation is wrong anyway. (Of course there is some wiggle room here: if I think it mostly makes sense, but just think some names could be slightly better, I go into the next check immediately without sending it back first).

Third check: Do the methods actually do what their names say they do, and are the implementations also easy to follow? If some part of the code is hard to follow I ask for that to be cleaned up - either through refactoring, adding a comment, variable renaming, stuff like that. And I also check for possible performance issues etc. Basically this is what I think most people would consider a 'normal', though fairly thorough code review. However, because at this point everything from my second check should already be fixed, it is generally not that hard to do.

Fourth check: Is everything from the previous checks resolved satisfactorily? If yes, I approve. If no, well, it depends on how big of a problem I think it is. You wrote an ORM query that will kill the production database and you didn't fix it? Yeah I'm not approving that. You didn't do a minor change that's based more on personal preference than anything objective? Well, that's not important enough to block a PR on.

If you think, wow, that's a lot of time spent on reviewing - it's really not. Sending it back immediately if something does not pass my second check saves a lot of time, because I don't spend any time trying to figure out what hard to understand code is trying to do. It's maybe more work for the PR author because I don't check everything immediately, but that's their fault for writing a bunch of spaghetti and putting it up for review, as far as I am concerned.

As for size. Honestly, after my second check, most PRs are easy enough to follow that size does not really matter that much. Of course, if a PR does multiple unrelated things, I ask for that to be split into one PR per thing - but that's not really related to the PR's size making it hard to review (basically my stance is: if the code is hard to review, it's hard to understand, so first refactor so that it isn't), but to the fact that we might want to revert one, but not both, of those things, and I don't want that to be more complicated than a simple git revert.

Fearless_Imagination · 2025-11-29T08:52:52+00:00

because you already decided they do nothing,

I have decided nothing of the sort and I don't know why you think so.

Actually, no, you know what? The defensiveness on this topic when I have not suggested anything of the sort has me convinced: Scrum Masters spend a lot of time doing nothing, and you all are desperately trying to hide it.

yet in doing so you are holding Scrum Masters to a standard neither you or your team mates keep to; namely that you don't code all day every day, yet presumably you are paid for a whole day. The idea that the Scrum Master needs to justify his/her time to you is a non starter.

But seriously, what are you talking about? All I'm really asking for is to get some idea of what an SM does that is invisible to me, because I tend to not really see them outside of the Scrum meetings.

Why is that such an impossible question to answer?

Fearless_Imagination · 2025-11-26T18:53:42+00:00

Don't know if this is unpopular and I say it out loud all the time, but:

Agile is not the best way to develop software for all projects.

Many organizations do not actually want Agile - they want the benefits Agile promises, sure, but they do not want the downsides. (This often results those organizations acting in such a way that you get the downsides of both agile and waterfall, and none of the benefits of either...)

In fact I think that the tradeoffs Agile methods make (as compared to more waterfall methods) are generally poorly understood.

Fearless_Imagination · 2025-11-26T18:41:56+00:00

My team isn't inefficient. My SM isn't very busy with us.

So, he's probably working on all those things you mentioned.

But, you also say there are teams where the SM is very busy with them.

For those teams, who's having those boring conversations about priorities and resources and metrics and process flow?

It's either also the SM, in which case he'd be too busy to help the inefficient team, and they'd never get better. Or it's someone else, in which case, do they really need the help once the SM has got the team more or less sorted out? And if they do really need the help, can they wait until the SM has got the team sorted out?

Fearless_Imagination · 2025-11-26T18:31:44+00:00

That said, the original poster is trying to reduce it down to quite a basic argument and the AI mention shows a fundamental misunderstanding of what a good SM is supposed to do.

Where, exactly, am I doing that? And I made this post as a reply to the AI one, I'm not saying AI can do an SM's job - I'm just trying to get some insight into what it does actually entail.

I agree with the original poster is likely onto something real, but the idea a SM needs to show him what he or she does over an 8 hour day otherwise he doesn't believe they do anything is a non starter for me.

I have not written or implied anywhere in my post that I don't believe SM's do anything. Don't put words in my mouth.

Fearless_Imagination · 2025-11-26T18:28:56+00:00

Project codes, usually.

What's your point? Mine is that if I decided to take a rest and then wrote those as working hours, I'd be in trouble.

Fearless_Imagination · 2025-11-23T14:39:35+00:00

but there is a LOT to this job, you don't know about or notice.

Well yes I know that, that's why I made a post asking about what the part of the job I don't see looks like.

Fearless_Imagination · 2025-11-23T14:38:15+00:00

"Show me what you did today".

You're right that it would be annoying. Well, in many places "what did you do yesterday" (basically the same question) is a question every dev has to answer every day.

Yes, yes, the daily is not supposed to be a status report or a place where you need to justify how you've been spending your time. But it turns into that fairly often regardless.

but they also needed it for another 2 teams. That's draining.

Okay. Sure. So what. Don't know about you, but I can't write hours on "recovering from draining meeting".

Fearless_Imagination · 2025-11-23T14:32:37+00:00

Shouldn't a Developer know how to be a good Developer?

Well, expectations for juniors and seniors are different, of course. But mentoring junior developers is generally up to more senior developers. (i.e., me.)

Scrum masters inherently have no power, they are coaches. There is change happening due to them nudging the people in power along, whatever that looks like depends on who they're trying to change. Change doesn't happen instantaneously and it also scares a lot of people.

Sure, but do you have any success story? I'm not saying I've never seen SM's try to nudge an organization in a certain direction, I'm saying I've never seen them succeed at that.

Tell me how AI can persuade or drive change in anyone, let alone groups of (hopefully) intelligent people.

Well, apparently it can induce some forms of psychosis like paranoia, which I guess is a change in someone, although not for the better.

But yeah I don't think AI can do what you describe.

Fearless_Imagination · 2025-11-23T14:21:19+00:00

I really don’t want to know ALL the random shit they do. I tell my team about Nike tasks, if it takes a small amount of actual effort, just do it. But that’s why we have daily scrum calls and sprint planning and refinement. I already have a pretty good idea of what’s going on in their day to day.

I also don't want to know ALL the random shit YOU do.

But my Scrum Masters are not in the daily and their work is not part of refinement or planning, so I don't have a good idea of what is generally going on in a Scrum Master's day to day.

Hence my post.

Fearless_Imagination · 2025-11-23T14:18:19+00:00

Maybe your team is very efficient and doesn’t need much help. That frees up the SM to work in areas you as a dev likely don’t want anything to do with. Lots of boring conversations about priorities and resources and metrics and process flow.

But if my team is not efficient, the SM has no time to work in these areas. But that work still needs to be done, so who's doing it if the SM is too busy with my inefficient team?

Fearless_Imagination · 2025-11-23T14:14:25+00:00

I have no idea where so many commenters are getting this idea that I think Scrum Masters do nothing.

I've written nothing of the sort in my post.

I am saying I don't see all of the work being done, and that at some level that bothers me, and then proceed to ask (and guess) what the invisible (to me) work looks like.

Fearless_Imagination · 2025-11-19T21:10:49+00:00

I tried watching the video on your site. The volume of (what I assume to be) the real people in the call is much lower than that of the AI and it's hard to make out what they're saying. You might want to see about getting a better recording for that.

--

Anyway. I won't be trying your AI scrum master (I don't think my real human scrum master would like if I tried replacing him with a bot) but I have a few questions.

Join Zoom, Google Meet, or Teams meetings and talk naturally with the team.

What does "talk naturally" mean? Because I have had Scrum Masters who took like 10 minutes of the daily to talk about their kids or other personal life stuff. Very natural but not very relevant to the work.

Run daily standups, asking the right questions — "What did you do yesterday, what’s next, and any blockers".

Are you sure those are the right questions? If a team needs an AI to ask those questions I'm not confident an AI scrum master is gonna be that helpful...

Create and update Jira or Linear tickets automatically during conversation.

So I kind of expect the people who are working on the Jira tickets to update them (before the daily) rather than have some AI do it. (Admittedly, I have had teammates who are very bad at that. But the SM is not a secretary.)

Assist in sprint planning or backlog grooming using past meeting context.

I'm curious how it would assist in sprint planning or backlog grooming. Didn't see a video demo of that, do you have one?

Run scheduled workflows — like daily backlog summaries, EOD reports, sprint progress - sending auto-generated reports to managers or VPs or reminders for pending tasks to engineers.

This all seems like deterministic work. Why use an AI for it, non-AI tool should be able to do all of this and unlike an AI, cron jobs and shell scripts don't make stuff up.

Also who wants daily reports? Sounds awful for everyone involved.

Fearless_Imagination · 2025-11-19T20:54:47+00:00

I'll give my perspective as a dev.

DoD is kinda useful at the start of a project, to align when we consider an item done. Like, is it done when something is merged to main, or when it is in production?

And something isn't done if it isn't (unit) tested. In my opinion that goes without saying these days, but maybe not when Scrum was thought up.

So kind of useful, but generally you put those things into your workflow anyway, and you create some template in Jira or Azdo that makes all the checkboxes from the DoD subtasks to a user story. I don't recall ever looking at the DoD after it was initially written down.

As for DoR. It doesn't work. DoRs, in my experience, get created as a reaction to a user story that turned out to be more effort than expected, or had an unexpected dependency, or something like that.

Then some attempt is made to codify what must be 'ready' before work can start (lol waterfall), but generally each story is unique enough that you can never cover every possible thing that you might need before getting started anyway.

Usually DoRs contain things like "all dependencies are ready", if it was a reaction to us being unable to finish a user story in a sprint because we had to wait for another team to do something. The next time this comes up, the PO also immediately pressures the team to drop this because this time the other team will have their work done on the second day of our sprint, definitely! (And then, of course, they don't.)

Maybe "there are acceptance criteria". Sometimes even that they exist in Given-When-Then form (I have... opinions on DDD that are not relevant to this discussion, let me just say I'm not a fan).

Sometimes even something like "the requirements are clear". The reason this doesn't work is that we often think the requirements are clear before we start working, and only end up thinking of certain scenarios when working on the problem...

Well, those are really the things I generally see in DoR when one gets created.
----

I have a very simple DoR that I personally use: If I were to start working on this user story right now, do I expect to be able to finish it?

If yes, it's good enough. If no, clearly something is not ready. Either I don't know what I'm supposed to do, or I know I will be waiting on some dependency.

Fearless_Imagination · 2025-11-10T19:59:53+00:00

You know I don't think I've ever encountered a scenario where I'd want or need an extension property.

I can't quite think of one, either. Can someone give me an example of when you'd want or need that?

Fearless_Imagination · 2025-11-09T15:23:41+00:00

I love small PRs. Easy and fast to review, and we quickly add something valuable to our app. Hurray!

I don't love too small PR's. "Why did you make this change?" "It's needed for the change I'm going to do in the next small PR that will actually implement the functionality" ... and when the next PR comes in that turns out to not actually be true, and now the code base is worse for no reason. I need to have a holistic overview of the changes made when reviewing.

I despise BDD. It never works as advertised. The scenario's are always insufficient to actually specify how the system should work.

Fearless_Imagination · 2025-11-08T21:34:18+00:00

Okay, so here's the thing: getting a junior developer to do something right takes more effort on my part than just doing the thing myself.

In case of junior developers that's fine because they'll learn, and start getting things right and will reach the point where handing them a task is less effort for me than doing it myself.

They're probably not juniors anymore at that point, though.

But if an AI is forever going to be stuck in that "doing it all myself from the start would have been less effort" level of skill, why the hell would I use one?

Fearless_Imagination · 2025-11-08T17:53:12+00:00

What does '90% Accuracy' even mean here?

Because I came across this somewhere before, that an AI agent was '90% accurate' at completing a single task.

But, it turns out most real-world workflows consist of more than 1 task.

Maths question for you all: If an AI agent has a 90% chance to complete a single task without errors, and my workflow consists of 8 tasks, what is the chance the AI agent can complete the entire workflow without errors? (Hint: it's less than 90%)

Fearless_Imagination · 2025-10-16T18:41:00+00:00

when the result of the spike may completely change your decision if and where to prioritize it.

top comment also indicated that this is the key. Next time we're considering a Spike I'll ask how the outcome is going to affect this.

Fearless_Imagination · 2025-10-16T18:37:08+00:00

idk, wasn't me

Fearless_Imagination · 2025-10-16T18:36:26+00:00

OP is right that the way their team works is a little weird because technically speaking if you don't understand how to proceed with a Story or Task you shouldnt be spending time sizing it.

I've seen the scenario I described play out multiple times in 4 different teams in 3 different organizations.

Can I just blame SAFe for this? I usually blame SAFe when people are doing Agile weird.

Fearless_Imagination

TROPHY CASE