Manager says my story points complete per sprint is too low. What should I do?
Posted by mcjohnalds45@reddit | ExperiencedDevs | View on Reddit | 349 comments
I'm a software developer. My manager and CTO told me that my average story points per sprint is below the company average and ask me to "defend" myself against this accusation.
The story point estimate for a card is usually done by the developer who is going to do the work.
I was under the blissfully ignorant impression that no sane manager would use story points to rank developers or teams.
I don't know much about my manager but up until this point, the CTO always been very competent and we've gotten along well, so this is all a big surprise.
Not sure what I should do. I would really prefer to not leave this company. I could treat story points completed as a KPI and do everything possible (short of dishonesty) to raise it. I could even have fun with this and try to be #1. They are paying me and they want more points so why not give them more points?
Sweet-Satisfaction89@reddit
He's being stupid and completely misunderstands story points, but your best bet here is "yes sir, i'll fix it" and just estimate your stories higher or break a 5 point story into four 2-point stories and get them done at the same rate.
TilTheDaybreak@reddit
Scrum master here, this is exactly right. Unless leadership is interested in moving past the silliness of “who does moster points” then the option is to inflate the points (smartly, don’t make it obvious).
CrankyOldDude@reddit
Wow - I’ve never seen anything as fundamentally broken as the idea that devs should be doing the work AND assigning points on their own.
I mean, great for the devs (and Op, I kinda judge you a little bit for not figuring out the game on this lol - j/k), but… wow.
AntDracula@reddit
Who else is going to do it?
CrankyOldDude@reddit
Story points are assigned by the team, not by a single dev. That’s the democratization of the value of work, and is a cornerstone of agile.
If I’m developing “Hello, World” and I am also assigning points all on my own, I can assign 500 points and look like a velocity legend.
The whole point is that the team consensus of the value of work is what drives decisions and helps inform reporting on velocity and things like that.
AntDracula@reddit
Okay. I thought you were referring to have non devs assign the points, which is a step more insane
Lurk4sho@reddit
As others have stated this is the answer. Sandbag the shit out of your story points. It's such an exhausting exercise but if they're tracking fictitious numbers to assess your productivity then they asked for this. Sandbag them, overcommunicate and just tell them what they want to hear. Keep detailed notes of why things are taking longer. Feed them their bullshit right back to them. It's a game and you have to play if you want to keep your job.
I'd honestly start looking for another job and then keep this one just stringing them along as long as possible. This type of measurement games are stupid and they deserve the gaming.
PragmaticBoredom@reddit
Blatant sandbagging will backfire. If you go from completing 5 story points per week to completing 20 story points per week overnight, the first thing your manager is going to do is look at the tickets. When they see a simple task assigned 5 story points you’ll be pulled in for another type of conversation.
What you need to do is right-size your story points, not sandbag. You also need to ensure that any extra work gets captured in new tickets, which count toward your story points.
But don’t go out and sandbag and think you’ve outsmarted your manager. This always backfires unless you have the dumbest manager on Earth, which is true rarely but not as often as Reddit will tell people.
theDarkAngle@reddit
But they're misusing story points, and that takes any notion of "right-sizing" off the table. It's supposed to be a relative and abstract unit, and all it does is facilitate forecasting, you divide total story points for a group of work by historical velocity of the team and get a forecast.
If you use it as an individual performance metric you've immediately rendered it useless. The whole thing only works if people are not thinking about themselves individually and they're not thinking about short term outcomes.
If short term outcomes and individual performance is more important than forecasting, then you should immediately stop using story points and start using hours or days.
At least that way they can provide more concrete estimates with some kind of rational justification if need be. If you say "I'm shooting for 2 days but it might be a week or slightly more esp if X and Y, so I put one week" that's a totally normal conversation and immediately comports with people's intuition about engineering and the inherent uncertainty.
But saying "shooting for 6.7 points but it could turn into 8, 13, or possibly 20" ... that is so meaningless and just makes it harder to communicate uncertainty.
PragmaticBoredom@reddit
You’re not wrong about them misusing story points
But a lot of managers do it anyway. When they do, you have to adapt to the system.
theDarkAngle@reddit
Yeah my original reply started getting kinda long and I cut it down, but I guess i cut out the main point on accident.
I was trying to say that basically, padding is essentially the right way to estimate if you're going to be held to the estimates on a relatively short term or even medium term basis.
Or really what I mean is it's not really even padding.
The truth is using our intuitive best guess, we underestimate a lot more than we overestimate for a variety of reasons, and then on top of that, naively we shoot for what I would call a 50% estimate. Which means something like, 50% of the time you'll be over, 50% of the time you'll be under. And we think that's fine because they'll balance out
But the truth is that doesn't really fly. The nature of the work is that when you overestimate, it tends to be a relatively small delta. You estimate at a week and it takes 3.5 days instead. Ok cool. But you almost never estimate one week and it turns out to be 4 hours.
But the reverse can and does happen all the time. You think something will take about four hours and it ends up taking over a week. That's just the nature of the work, and the particular kind of uncertainty we face. There's a reason planning poker deltas use a fibonacci sequence.
Realistically what tends to balance estimates in the long run and make everyone happy, rather than 50% estimates, is something like 75-90%, or maybe as high as 95% (these are not rigorous probabilities obviously, just rough abstract approximations). E.g. "there's a 95% chance that actual work will be at or under the estimate"
Anecdotally, 80% is the number that best fits my personal historical data. 80/20 rule I guess.
Now if you actually sit down and analyze a non-trivial, real world task thoroughly and try to find a number for where you really feel good about saying "80% chance of meeting the estimate", you'll often find that your result is as large or maybe even larger than if you just crudely padded your raw intuitive estimate.
Nowadays i put together a spreadsheet for my estimations with a bunch of step wise breakdowns of tasks. I put an initial estimate and an uncertainty factor for each step, and I add notes as to why, and ultimately produce a few of the different confidence interval estimates I mentioned.
I give the 80% number for everything. And if I get push back from managers (which has only happened twice and not for a long time) I just send them the sheet and say use whichever number you want to, but understand what it means. And understand if a project goes over budget, I have this work to justify my estimates, and they'll have to come up with a reason for why they applied downward pressure on the estimates.
MiniGiantSpaceHams@reddit
It doesn't have to be sandbagging. The below average story points are either because OP is actually underperforming, or because they are using fewer "points per complexity" (if you will) than the rest of the team. Assuming it's the latter, it's not unreasonable to ask OP to adjust how they estimate to be more in line with the rest of the team.
topological_rabbit@reddit
"When a metric becomes a target, it ceases to be a good metric."
SituationSoap@reddit
Sandbagging only works if your boss is completely and totally stupid. It's entirely possible that "hey your story points are low" is the boss trying to give a very soft entrance to the conversation of performance concerns.
I have been in the position where I've given someone the feedback that they're not getting enough done and their response was immediately to just start inflating estimates. It did not go well for them because I am in fact not an idiot and am not judging them based on an easily-gamed metric.
Lurk4sho@reddit
Without more information, we have to assume OPs boss is an idiot and is judging them based on an easily-gamed metric.
Any manager/CTO/company that uses story points to discuss performance are idiots. You can't convince me otherwise.
SituationSoap@reddit
Assuming that the person who holds power over your continued employment in a bad job market is an idiot is a sucker's play.
Well, have fun betting a job on the idea that your manager hasn't figured out this incredibly simple and useless response.
Lurk4sho@reddit
Assuming that OPs boss is an idiot on an anonymous internet forum is different than working with the boss day to day. Let's not conflate the two.
Do you have a point or are you just trying to troll random comments on an anonymous internet forum.
SituationSoap@reddit
Yeah? What about when you're giving that person advice for how to handle an interaction with their boss?
"It's anonymous, none of this matters" is a stupid response. Stop turning your brain off.
Yes, my point is that you shouldn't give the OP shitty advice because you'll score some stupid points on an internet forum. You should take what they wrote seriously and give them useful, actionable advice.
Giving serious advice from the perspective of someone who's managed underperforming developers before isn't trolling.
The intention of this subreddit is to be a place where experienced developers can have useful, productive conversations about the problems we all face together. If you think it's just some bullshit forum, you're allowed to fuck right off and not come back.
Lurk4sho@reddit
Ok troll. Have a good day!
mcjohnalds45@reddit (OP)
Thank you.
My initial response was to argue that story points can't be used like that. That was the wrong move.
I will ask and see if low story point average is really the issue. Then I will make my story points completed per sprint chart look great. Really great.
Bowmolo@reddit
You are right.
If you want to continue arguing, do a analysis whether your teams estimated SP correlate with the duration to finish a Story (so-called Cycle-Time, time between starting to work and finishing it). This can easily be done using some Spreadsheet Software.
Typically, you will find no correlation.
But isn't that the basic assumption of estimatation, that this correlation is high and estimates indicate how long it will take to finish some task? And is there's no correlation, what's the reason for estimating at all?
This is a tough argument, because many people WANT to believe in said assumptions. Hence, you might still lose that debate, but at least you then argue based on data.
Again, think about whether you really want to argue.
mcjohnalds45@reddit (OP)
Clever. I might do this analysis out of curiosity but I probably won't bring it up with them.
Bowmolo@reddit
I can tell you that out of 20+ teams and Team-of-teams I've not found a single case where that correlation is high. Hence I consider the predictive power of SP estimates regarding the question 'When will it be done?' to be zero.
CasualEarl@reddit
Stop arguing, now. You will never win by arguing with a manager.
"Yes sir, let me fix it" and just weaponize the game against him.
ayananda@reddit
You can win some arguments by blocking the initial confrontation by saying something like "luckily there is no idiots here who would think x or y" If you are sniffing that somebody going to go that direction. It's risky...
SituationSoap@reddit
Calling your boss an idiot to their face is a really stupid approach to being told you're not doing enough work.
ayananda@reddit
I was talking more generally. The idea is that before management goes that far you try to block that idea from going further. It works when the timing and situation is correct.
NoCardio_@reddit
You’ll never win an argument with a BAD manager, which definitely applies here.
MathmoKiwi@reddit
There is a phrase in politics "explaining is losing" which is highly accurate in politics, but I feel it is also relevant in some many other areas, such as u/mcjohnalds45's situation.
It might "feel" great to "explain" (argue!) your point and to "win" if you successfully make your point, but in reality you're still losing. (and doubly losing if you fail to get your point across, which is the most likely outcome)
SituationSoap@reddit
Of course they can.
Like, setting aside all of the other stuff you have going on, here. Your boss is allowed to run their team however they like, so long as it doesn't violate laws or company policies.
This is one of those things that you super have to understand, because your boss is communicating that you're not doing the job to their satisfaction. Their reasons for that might be good or bad, but ultimately the reasoning is irrelevant. They're allowed to judge your work however they want and you have to live within that reality. You don't get to appeal to some other, different reality to say that actually, things are just fine.
You can adapt or you can leave but you can't force your boss to adapt. That's not going to work.
RememberTheDarkHorse@reddit
This is good advice. And if your manager thinks your aren’t doing enough, some easy fixes are:
Over communicating- message him about things your are picking, getting stuck on, or just more status updates
Adding more stories for the small things you do but don’t track like going on-call or mentoring someone
Make note of things you do so in standup you say a bunch of things and not like… “ummm yesterday I worked on 1024”. Instead- “yesterday I helped Jo with his env, I answered some product questions, I looked at Susie’s MR, and got the API done on 1024”
Megamygdala@reddit
People always say this but I can't imagine spamming your manager with updates they couldn't give a single shit about being helpful
RememberTheDarkHorse@reddit
Managers actually are like you, hyper focused on their own thing and too busy to go chasing around status updates.
So we appreciate you taking the guesswork out of it
Kaimito1@reddit
I recently heard some advice which kind of sounds true.
"Unsolicited status updates on tasks you were delegated makes you look productive. But it's the inverse if the manager has to ask for one first"
chrisfrederickson@reddit
Am a manager. This feels generally true. All depends on the situation though.
Silence from someone who consistently performs well and is quick to raise issues historically it doesn't really matter. I may reach out just to check on things to be sure I'm doing my due diligence, but I trust they have it covered.
Regular status updates are great if you are new or struggling with things. I'm there to provide support. If I've been kept in the loop the entire time, it's really on me if things aren't going smoothly.
If I reach out and there is a 50/50 chance there is actually a big issue. Or you completely catch me off guard because of a lack of communication. That's the problematic pattern.
PeachScary413@reddit
Exactly, make sure to mention every reply on Teams or email like you made a valiant effort and really helped pushing productivity. That two line fix you did in 10 mins yesterday? That's a major bugfix that you managed to pull off after wrestling with it for a while.. for bonus points schedule your emails late at night so it seems like you sat up all evening working hard on the issue 👌
Never ever downplay something as "Oh it was just a small thing" or "No worries I can do it quickly, it's an easy fix".
shootersf@reddit
Whoa careful with the schedule emails late. My manager would see that as you struggling to do your work within work hours and it would be a big talking to.
PeachScary413@reddit
I think key is to really puah on the massive complexity in these absolutely mission critical bugs that you are fixing.
But you are right.. it could be interpreted in the wrong way 🤔 another more foolproof method is the "collector". You simply note down bugs that you find but you never fix them, wait until they get into production and then when there is fire everywhere you bring out your cape and save the day quickly 🫡
From zero to hero in no time.
abraham_linklater@reddit
Good advice. Some managers confuse the map (Jira) for the territory. As long as they see a declining burndown chart and a bunch of tickets in the 'done' column, they're happy.
puzzleheaded-comp@reddit
Love that analogy you just used
RightHandMan5150@reddit
This. Take your first, off the cuff estimate and multiply by pi.
grumpy_autist@reddit
My asshole manager uses github commit stats to shit on me during my performance reviews. I squash commits before making a PR while other team members have a separate commit for every typo and unit test name change.
Well, guess what who is now flooding GH repos with useless commits and splits each PR into 4 smaller ones.
thekwoka@reddit
Why?
You should squash merge the PR...
grumpy_autist@reddit
No, we have this disabled for our repos. Don't ask me why.
thekwoka@reddit
That's crazy. Everywhere I've touched had it as the only allowed merge strategy.
UncleSkippy@reddit
Set up a script that runs every 10 seconds and checks a diff on your changes. If it exceed 10 lines, have it commit. Hell, tie into an AI of your choice to have it come up with a generic commit message so they vary every time.
ShoePillow@reddit
Everyone on the team?
AccomplishedLeave506@reddit
Every comment deserves it's own commit. And then another commit immediately after when you realise your code is too high quality to need the comment as it's the most readable code ever written. Possibly need a commit in between those two commits to fix the inevitable typo.
Hell, why not commit per character change. Just to be sure you can revert to the exact point you need to.
IceMichaelStorm@reddit
Bear with me, but is it? I mean if he puts his own estimates ok, makes no sense. But jf the team estimates it and he completes over a longer time only 2-5 SP per sprint and others 10-15, then… he could be super productive still like maybe helping others a lot. But there must be reason right? In this case, finding out the reason from CTOs perspective NEEDS to happen. Like, the metric is pretty shitty to take on its own but wouldnt it be a signal upon which to take a closer look?
AccomplishedLeave506@reddit
It's about as useful as who comes in first and leaves last if your still office based. Maybe it's an indicator of work output, but generally it isn't. You could use it as an indicator to then look further into work output from someone I guess. But it really is a very weak indicator of anything.
Where I currently contract one guy is the darling of management because he absolutely flies through tickets. If you look at the tickets he's doing they're all very simple and can be done with little effort. I barely do any tickets, but that's because I'm mostly sitting and thinking about how to restructure things so we have less tickets overall. To management it looks like I'm slow. But the stuff I do magically just appears after a period of time and then works. No more tickets to fix things or running around refactoring it to allow new functionality. I honestly can't think of any easy metric you could use to find my 'worth'. Story points? Lower than everyone else. Commits? Lower than everyone else. Lines of code? Way lower than everyone else and negative on a good day. But I just got renewed for another year because they looked at what I have worked on and realised large chunks of it are the core of their system. Probably confused a few people.
SituationSoap@reddit
The metric is what you've negotiated out with management what success looks like for your job. This gets squishy as you move out of purely development-based roles into what some teams call Staff and some teams call Technical Project Management and some teams call Lead work.
It might be reductions in overall team cycle time or churn, or increases in velocity. Sometimes you don't have an individual metric to track someone's work, but instead you're looking for their impact across the whole team's metrics.
Codex_Dev@reddit
Honestly it's super hard to measure performance based on metrics alone. It's like identifying if a mechanic is good based on the number of jobs he performs or how much he is paid. Someone might be REALLY GOOD at doing oil changes, but that doesn't mean they are any good at ripping out the engine and rebuilding it from scratch.
Tbh I love using car analogies for code because a lot of non-coding managers guys can relate to it easier and understand.
AccomplishedLeave506@reddit
Plus the really good mechanic gets assigned the job that nobody knows how to do. So he/she has to spend a week learning how to do it and then twenty minutes getting it done. Next time someone has to do that job they can ask the top mechanic what to do and then they do it in an hour. Are they better because it took them less than a week? Might look that way to a bad manager.
Honestly, I'm tired and bored at the moment so I'm coasting. I get twice the output of anyone else done because I'm old and I've done it all before. I could do 5 times as much of I was motivated. But I'm not. And my output has a quality that exceeds what is needed by a long way. How do you measure that? Do you fire me because I'm slacking, or do you give me a 50% pay rise to make sure I don't leave and cause a large drop in output from the team?
They can't measure what I'm doing. They just know when they give it to old grey beard who rolls his eyes and mutters about going on holiday. And then a bit later they have what they want and they never have to think about it again. Must be extremely frustrating for management, but thats not my problem. I'm sure they know I could do far far more as well, but how do they prove that? And they can't make me because I'm bored. They can fire me. But then the next time they need someone to spend a week working something out it'll take the team a year and it won't get sorted.
mcjohnalds45@reddit (OP)
I also cannot imagine any good metric.
There is no way to measure all the code that I didn't commit because I refactored and ended up with a smaller line count. Or all the bugs that didn't happen 6 months from now.
IceMichaelStorm@reddit
Great example, yeah! Metric nope. But many positive other signals and clarity when talking with you or others
therealdukeofyork@reddit
Good devs add sloc. Great devs remove sloc.
killbot5000@reddit
Plus one to this. Story points are such a handwavy metric already. Just double the story points you assign to your tasks. Triple it if you want to stand out as a 10x dev 🤪
KYDLE2089@reddit
Agree story points should not be used to measure someones performance only idiots that don't understand and just want to look good on their own status calls with their bosses. This can turn into a bad culture.
Mostly seen this with indian managers - no offence to indians its just some of them are bad managers more than others.
riotshieldready@reddit
This is exactly what I did. I wasn’t being track for points but simply PRs per month, which is so dumb. My team mostly did big complex tasks so I would normally have 1 PR a week, I just broke it down into lots of small tasks, went from one of the worst in the company to the best. My work quality or speed never changed.
mamaBiskothu@reddit
The reality is in many places management uses story points to have this difficult conversation in a legally defensible way. Its possible they're only measuring OPs output using story points. Its also possible they had another conversation privately, "hey, what exactly is OP up to? It doesn't look like they're pulling their weights. Is there sprint velocity showing the same?"
At least thats how the conversation goes in my org. It's not a perfect place but at least this part i understand from a managers perspective.
OkLanguage6322@reddit
Oh man! I give some points without putting in much thought. 4 things here — 1. My Manager is very hands-on and technically gets the drift 2. We usually know the deadline so in the grand scheme of things nobody actually cares about the points as long as the deadline is met 3. Nobody is quantifying it (yet?). I mean it’s a little hard to quantify and that each team works differently. 4. There is a general trust among the team. I am going to shit on my teammate if he/ she gives a higher point score than what I think. We generally approach with the attitude— maybe there is something that I have missed or don’t understand and have a 1-1 conversation about what the teammate is thinking.
CompetitiveStreak@reddit
Real answer is start looking for another job. I doubt this the last toxic thing they're going to do to you
Stubbby@reddit
They call the estimations "Planning Poker" because everyone is bluffing.
Apprehensive_Elk4041@reddit
I thought it was because by the end of it almost no one was wearing pants anymore.
Stubbby@reddit
The pants are down at release, not at planning :)
Lgamezp@reddit
Story points is NOT a metric. Its not even part of the scrum guide. It serves as a way to express relative complexity.
The key part is relative.
How does your manager know its too low? How does your manager know a story is X points? Even if he does, you taking on a 3 point story, might be a 1 point for me or 5 point to another person (hence why the whole pointing in group shouldn't be a metric either way).
Quick fix. Point everything higher than it is to give you space to breath. Unprofessional? Maybe, but so is your manager. And its only unprofessional if you don't work.
Apprehensive_Elk4041@reddit
Even worse, where I used to work, we'd have managers frequently come in on estimation meetings and veto the team's estimates if they were too high. They would 'gently persuade' their direct reports what the estimate should be, and then bludgeon anyone that didn't get it done in the 'agreed to' timeframe.
Scrum master would just allow it. That place was an absolute mess and organizationally very broken.
Lgamezp@reddit
Ugh, by any chance were they using sAfE? Most horrible idea ever.
PedanticProgarmer@reddit
Yet. I was in 3 teams that were forced to do Scrum 🤡. In every single case, the story points was the most important aspect of the process. Business value? Sprint goals? Well written stories? Customer feedback? Who cares. The SP metric and the burndown chart was what the management really cared about.
Apprehensive_Elk4041@reddit
So my two cents (I came from a place where they tried very hard to use these metrics and made a mess).
A) it's a rough job market right now, it really sucks, I would NOT leave until you have another offer accepted, but given the choice I would leave. If you're being talked to about this two levels up, they've already decided you're the problem. That is a lot harder to overcome than getting more stories done. We had an idiot that took one stats class and decided to play the numbers from jira as a direct management tool org wide (well over 150 developers) and it did not end well. Not at all, it made a huge mess of over estimation and negative feedback loops that exacerbated the smaller problems that were already there.
B) at its core this is a severe misunderstanding of pointing and why it's done, which isn't a good sign. If your management buys into this, it's a good sign that it's a really poor management team (unskilled or inexperienced in one way or another). That's not the job you want to be in, I'd start applying, praying (job market is terrible or was as of a month ago), interviewing and sharpening your skills for the next move.
C)The job market is terrible, meaning I've done programming for almost 20 years and I would not believe what's going on out there if I hadn't seen it because it's so bad and so different than anything I've experienced. I think it's starting to ease up, but there's a real mess. You will not likely get a new job quickly, be prepared. If you lose your job you may be unemployed for a long time (I was for about 3 months [and I was very lucky from what I've read], I was prepared for maybe four weeks of no income).
D) You don't want to be there, but do nothing to risk that job at all. Yes sir, no sir, make a plan to fix it. Make sure the plan is reasonable, measurable, and that you measure it. You are preparing a counter case against them firing you from this point on. Do it quietly, don't talk about it or show anyone, but prepare your defense (because they're having you prepare your own prosecution via jira). Don't sandbag estimates, but give yourself more space because you clearly need it, you (or the team as a whole) are clearly under-pointing. This can be due to not estimating secondary non-development tasks in there (like getting it through to qa and then prod), governance steps required (review boards for releases, release process doc creation and approvals), not enough time for meetings, and all the secondary crap that must be estimated in. Points aren't arbitrary, don't be confused. Points are time in the mind of management and project planning types, so for most places the mystical ephemeral create called '8 points' is actually just two weeks. Forget all the nice talk, it's not a statement of 'general complexity' in practice. It's a measure of time that project managers use to populate dependency plans for feature release. That means you are committing to doing it in two weeks. Especially if they're managing to commit to close.
mcjohnalds45@reddit (OP)
Thank you. I mistakenly believed that story points meant time + complexity + risk or something. Madness. No, actually, 1 SP = 1-2 days. Now it's clear.
warm_kitchenette@reddit
I've seen a lot of non-tech project managers with that exact translation. You're right, they are wrong, but you have to play the game that they're laying out. You have a variety of reasonable moves: sandbag estimates for certain tickets, divide them out into sub-tasks where you can show constant progress as the sprint moves on, create some tickets or sub-tasks even when you've already done the work elsewhere or know you can do it in a fraction of the time. A manager or PM will suspect the first one, so be judicious. A less reputable move is to cherry pick the tickets, avoiding risk in favor of certainty.
I also agree with the other point: the job market is super rough. Don't jump ship. Just play the game.
Apprehensive_Elk4041@reddit
Just to reiterate the job market is rough out there, make sure you hold tight and do whatever it takes to stay until you have something new too. The job market has been worst than I've ever seen in my life. It's really bad out there, and while I'd be looking for an exit, I'd hate to see anyone jump right out into that cold voluntarily without something else ready to step right into. The job market is really hard and messed up. I think how we hire has been consolidated, automated, and slapped in to a bunch of weird places and it's not working out well for either employers or job seekers.
fllr@reddit
Interview
Perfect_Papaya_3010@reddit
Sounds like they don't really know what coding is about?
Fix a typo = one story point
Implement a complex login with Auth and all kinds of security= one story point
Ask him if he thinks these two both counts as one
rfpels@reddit
Run. Your manager and CTO don’t understand the most basic thing about Agile. One cannot do arithmetic on story points because story points are ordinal numbers. They indicate where a story is placed on the complexity scale in relation to other stories. They also will not understand that story points burned down per sprint cannot be compared between teams because every team has it’s own idea of how the complexity scale looks.
I will say again: You cannot do arithmetic with ordinals. Ever. That is the reason for the 1-2-3-5-8-13-20-40 sequence. You also cannot compare complexity scales between teams. It is quite possible that one team places the same story at ordinal 8 and the other team places it at 20. 2.
Apprehensive_Elk4041@reddit
But don't run until you have some other hut to duck into!!!!!
Get the new job first, then leave the old one, it's BRUTAL out there right now, I just came in from the cold.
SituationSoap@reddit
Your boss and CTO are telling you that you're not doing enough work. Why do you need reddit to tell you what to do?
bwmat@reddit
No, they're saying their foolish metrics indicate that
Apprehensive_Elk4041@reddit
you're 100% missing the point. The justification doesn't matter, the message is what they'll act on (and maybe have already decided to do so and are laying the groundwork to get rid of you).
SituationSoap@reddit
It doesn't matter why your boss thinks you're not doing enough work. Your boss could be telling you that you're not doing enough work because their astrology chart said so.
The point is that your boss's perception of your work is that you're not doing enough of it. That's a clear, straightforward message. Your options are to do enough work to satisfy them or quit. This is not a hard problem.
SongFromHenesys@reddit
Who the hell does story points at this day and age? :O
Master-Broccoli5737@reddit
we use it as a time sheet tracker. 1 point = 8 hours.
SongFromHenesys@reddit
What's the use for the point then? Why not just the hours?
Master-Broccoli5737@reddit
one of the great mysteries of the universe
Apprehensive_Elk4041@reddit
Beware looking too long into that darkness, you find it staring back at you
SongFromHenesys@reddit
Must be the scrum master's job security :) (assuming you have one)
ings0c@reddit
Literally everywhere I’ve ever worked in my 10+ year career has.
The only exception being one of the teams I’m on now, because it’s a maintenance contract and I’m the only dev.
SongFromHenesys@reddit
I've also been in many teams who did that, but luckily the past 2 eng managers I worked with understood that story points are useless, and we just estimate in:
xabrol@reddit
I just start cutting cards for every little thing I'm doing in the middle of the day.
Pair programming to help another dev on their card? I maje a card and give it a story point or two.
Random 2 hour business meeting, I cut a card like " knowledge transfer to higher level business tiers" 2 story points.
1 on 1: " knowledge transfer to manager" .5 points,brecurring every sprint.
Stand-ups running over for 2 hours "miscellaneous meetings" 1 per speint, 5 story points....
Apprehensive_Elk4041@reddit
Yep, I did this as a lead, they did not like it and asked me to stop very quickly because they didn't want to face the reality they'd created, or have the tools to fix it (some of which wasn't their fault).
bwmat@reddit
No problem, send them an email telling them you need them to create the card, and paraphrase all the information so they can't just copy paste
Naibas@reddit
By definition some people will be below average. The inverse to this question is: "You're above average for story points. Are you estimating appropriately?"
Story points are an estimate used to guide decision making. Nothing more. I suggest your team start pointing as a team to recalibrate.
Apprehensive_Elk4041@reddit
Ohh, but it's so easy to make charts out of numbers. I want to. I want to make it a bar chart. They're just so cute.
I'm doing it. I'm making a bar chart out of it to try and avoid having competent technical management, or more often because I don't trust the development organization's technical management.
titosrevenge@reddit
I find it humorous that each individual developer points their own tickets. We point at the team level, so that the points are representative of the complexity of the task and burial agreed upon by the team. You can't bullshit your estimates as easily when the whole team has to agree on the estimates.
In your situation you could easily inflate your estimates and get back on track in terms of their productivity metric.
SnooGTI@reddit
Everywhere I’ve worked that points as a team I feel we always end up over estimating anyway. It’s like an unspoken rule.
AdHoc_ttv@reddit
That's totally fine. If every "actual 2 pointer" is called a 3, you still have consistency and predictability.
Apprehensive_Elk4041@reddit
I worked at a pretty big company, and any '2' or less was thrown out because there was no such thing as a 2. No work could be pushed all the way through the process to completion in 2 day's worth of effort.
We had a really good scrum master though.
dragonsmilk@reddit
Exactly. The incentives are still aligned anyways. If we all pad, then we all look productive every time, no matter what. Some sort of developer omerta.
With all the PMs, managers, executives, and such bullshitting constantly and playing politics and shifting the blame, padding is the LEAST you can do as a proactive defense.
zerocoldx911@reddit
They’re warning you that if you don’t keep up you’ll be PIP.
MinimumArmadillo2394@reddit
Exactly this. OP needs to start 2xing or 3xing their story point estimations. 2 is bare minimum for one liners and 5-7 needs to be standard. For long ones, minimum 10-13.
OP could also take 30 minutes per story to do an estimate themselves, then update the ticket.
xmBQWugdxjaA@reddit
Then they ask you to split up tasks above 8, and soon enough you're spending more time dicking about in JIRA than actually solving problems.
Apprehensive_Elk4041@reddit
But if that's what management wants, that's what they'll get. If their process of managing workflow, incentives and punishments leads to inefficiencies they find intolerable, that's their decision to change the rules of the game. As is, they've set the rules, and splitting stories, managing point estimates to be realistic with required buffer, these are all just costs of the way they've set you up to do your job.
If they don't like it, that's their world to change.
csanon212@reddit
My life for real. Writing detailed acceptance criteria on 3 small tasks which do nothing for the business by themselves is the opposite of agile
xmBQWugdxjaA@reddit
Sorry, I need a Definition Of Done in this comment.
feuerwehrmann@reddit
You forgot to check the dod box saying documentation is complete, move the documentation task to done, And put a comment in the main story
PlugAdapterTypeC@reddit
How many projects have you worked on? Every project and every team have a different velocity and point scales, you can't generalize like that. No offense but you sound very junior
Jaeriko@reddit
They're saying they need to inflate it to higher levels, not that 2 is the minimum amount of story points for any work at all. A standard three becomes a 5/7, 5/7 becomes 10/13, etc.
solidgraystone@reddit
This exact scenario happened to me. My shitbag manager who was just assigned to me for three months, complained my story points per sprint do not match up with another developer.
One month later, I was pipped. Less than a month later I was terminated.
Play the game.
zerocoldx911@reddit
Yeah there are always signs
AWeakMeanId42@reddit
PIP if you're lucky! I got fired (for underperformance) despite having a solid annual performance review only a couple months prior (including a raise). I worked like 240 hours in my final month and had just demoed to the other devs my progress--with which they were thrilled. I wish I had gotten a PIP...
csanon212@reddit
Apparently the new thing is straight up firing at the end of six month probationary periods.
At my previous company your performance ratings was only given if you joined more than 3 months ago.
Managers would game the system to hire someone 4 months to performance cycle, and then just fired them at like month 5.5 because they were still under probation. Apparently it gave them a sort of no-fault hire metric so they could more easily hire someone else.
This one manager did it 3 times to some freshers before the director said stop. Worked out badly for these people just out of college.
zerocoldx911@reddit
Big companies tend to do PIP instead due to liability
Miserable_Double2432@reddit
This is the really important part of this conversation, the story points thing is not.
Assume that you are already on a PIP and they haven’t told you.
Your manager and CTO are not watching all the story points and suddenly noticed that you were an outlier. They already thought you were underperforming and the story points are a (admittedly very stupid) attempt to justify why they’re thinking that.
You need to work out why that is. Look at the code, design docs, Jira tickets and Slack conversations that your peers are contributing and see how you’re matching up to them (Peers meaning people with the same level in the company/department, not just people on your team).
Focus on making sure that you are at least completing your sprint commitment. Break large stories down into smaller parts, the Fibonacci scale incentivizes this. An eight pointer becomes two five pointers, and they become four three pointers. A net gain of four points without being dishonest. (This is by design. An estimate for a small task is more accurate because there’s less uncertainty)
Padding an eight to a thirteen is also likely to work against you now because your manager will be watching for that and will use it as further evidence that you’re not pulling your weight
Neverland__@reddit
Sometimes? More often than not haha
samsounder@reddit
Don't be dishonest, but its a false metric. As a manager, I avoid this measurement because it causes point inflation, which hampers our ability to actually measure what we're able to ship.
You need to start inflating your points. It sucks, but that's the only way to play this game.
twinklytennis@reddit
Gotta love the prisoner's dilemma.
bwmat@reddit
I would rather complain what they want is dumb and then loudly complain when I was fired for it tbh
Apprehensive_Elk4041@reddit
You have found a family here, you are safe now, and welcome.
bwmat@reddit
Reminds me when we were having some large team meeting about how they were going to start tracking this kind of thing and I just burst out with "so we're going to inflate the estimates right"?
And the manager was just like "Matthew!" with an angry look and then continued on to assume other subject
VizualAbstract4@reddit
My favourite reaction to elicit is always, “god damn it corey”
Codex_Dev@reddit
Honestly, some of the best managers I've worked with have been like this. They are "supposed" to get angry when you show honesty like this, but they don't go out of their way to punish you for it.
agumonkey@reddit
society makes this mandatory sadly.. honesty is so rarely rewarded
Apprehensive_Elk4041@reddit
I think I'd say the same thing in a different way. Developers almost universally underpoint stories. They point based on what code is required, not everything else around it (stuff like unit tests, qa support, release documentation/tickets, etc). Almost universally developers also overestimate their personal aweseome-ocity and are only thinking of the primary use cases (this is correct, and how they should naturally think, but they should be aware of this and actively fight it in a few specific places of their work).
This is especially true in a larger organizations. There is a general thought of 'how long will this take to code', but that's not the job, it's the coding, code review, test automation, any governance or shepherding to get the code into and through the QA step and ready for release. The job isn't coding it ; the job is getting a feature to the customer and delivering business value, and often that takes a lot more.
In a bigger org, for a bunch of super valid reasons, the coding side is often the easiest and quickest part of that whole process.
Soccham@reddit
The only useful thing for story points is to do a very rough comparison of teammates over a long period of time and even that isn’t perfect. But if 5 of 6 developers are consistently doing 10-15 points per sprint and OP is doing 5 there’s likely a problem depending on levels
Lgamezp@reddit
What if the stories are different (e.g. he has database stories and he is a better frontend, but the others are even worse at dba?).
Story points are relative and shouldn't be a metric ever.
samsounder@reddit
I have made this point using data at many companies and will make it at many companies in the future.
Story points are stupid
MoreRopePlease@reddit
Story points are a tool to help the team plan a sprint, and be predictable in what they can deliver They have no meaning otherwise.
qts34643@reddit
Exactly, story point are very useful when they stay within the team.
Soccham@reddit
If you’re constantly at that large of a discrepancy between completed story points between people at the same level on the same team then your team sucks at pointing stories. Mind you that it’s not a sprint to sprint measure. But if Staff engineer A is always doing 2x the points of Staff Engineer B something’s failing in your planning process.
fizzydish@reddit
Or you know, they’re choosing all the easy stuff, inflating their estimates or constantly asking for help. Measuring individual output on a team based process is insane. Why on earth do you want to incentivise your engineers to compete with each other when the most effective way to get productivity is to work together with high psychological safety. As to the argument about coasting and people not pulling their weight, their colleagues will know and if they trust their management they’ll tell them.
Soccham@reddit
Above it says “it’s only useful for a very rough comparison over a longer period of time and an indicator of a problem.”
Not that the problem is “fire this one dude” the problem can easily be “everyone else is always taking the easy shit.”
Good lord yall are sensitive today about your lack of outputs
SituationSoap@reddit
This sub is full of a lot of people who are chronically bad at their jobs (and frankly, jobs in general from some of this advice) and have built up a whole pile of defense mechanisms to rationalize that fact.
MathmoKiwi@reddit
Did u/mcjohnalds45 explain how big the gap is vs the average?
As it's a big difference between if they're averaging 5 but company average is 6, and the manager is just showing mild concern over what is nothing at all and OP can quickly fix with a little massaging. Vs if they're doing 5 but company average is 15 and the manager is seriously concerned about this "massive" gap.
MoreRopePlease@reddit
Since OP does the estimates, maybe they suck at estimating?
AccomplishedLeave506@reddit
That really depends on how the tickets are doled out. If it's selected by the developer then you can very easily end up in a situation where developer race to take the easiest tickets and then you end up with one guy who does the hard stuff because they can. You really really don't want to get rid of that guy because they're doing less story points per sprint.
It's no better a metric than lines of code.
Soccham@reddit
Above it says “it’s only useful for a very rough comparison over a longer period of time and an indicator of a problem.”
Not that the problem is “fire this one dude” the problem can easily be “everyone else is always taking the easy shit.”
Good lord yall are sensitive today about your lack of outputs
Codex_Dev@reddit
I've heard some horror stories on reddit of some employees doing exactly that. They would be the first ones to pick the easy tasks so that new hires would get the super hard and complicated stuff which would cause them to get fired for low performance.
AccomplishedLeave506@reddit
Every problem I've ever encountered in the workforce eventually comes down to bad management. The general quality of software engineers is appalling. You could fire at least 80% of the engineers I've worked with and the change on work output would be barely noticeable. But management is even worse. Out of hundreds of managers I've worked with I can only think of 2 who actually made the work easier and more efficient. And the higher up the management tree you go the worse it gets. The people at the top are almost all sociopathic idiots who's only skill is stabbing the right person in the back at the right time. Companies work in spite of them. Not because of them.
Own_Attention_3392@reddit
It sounds like points aren't decided by the team, but by the individual delivering. So the problem is that one person underestimates and everyone else overestimates.
This is also why points are a shitty measure of productivity.
Soccham@reddit
They don’t have to be if the team points as a group and points for how they’d expect a mid level engineer to complete the story.
LargeHandsBigGloves@reddit
And does it sound like they do? Not a huge leap lol
SadTomorrow555@reddit
I had a meeting where I specifically told my company I will be raising my average points per ticket lol. I was outright about it.
revrenlove@reddit
I've had several awesome managers that would just default my estimate to 3x whatever I said.
Not that I was slow, but they knew I spent more than half my time mentoring and helping coworkers on their tasks.
Their higher ups wouldn't go for me having "less velocity" than the juniors.
g0fry@reddit
Why wasn’t mentoring and helping others tracked as separate tasks?
revrenlove@reddit
There's no "tangible" testable acceptance criteria
g0fry@reddit
Interesting aproach 🧐
Korzag@reddit
Furthermore there's no deliverable. This is the crux of the issue with using velocity as a KPI. Upper managerial types really have no fucking clue how to tell how well we're doing our jobs outside of trusting their reporting managers and seeing that things are delivered.
revrenlove@reddit
That's a bingo
agumonkey@reddit
and it's often done on-demand and just-in-time during fire or incidents.. zero planning unless it's an official part of the culture
Codex_Dev@reddit
Even when I try to give good estimates, they almost always end up being x2 or x3 due to unforeseen bugs or problems that arise. A lot of times it's not even my code that is causing the problem but someone else's code that is fucked.
Additional-Map-6256@reddit
I was "fired for performance" for not meeting an estimate at a waterfall company where my manager just assigned random hours to projects. He even admitted that they didn't look at the code or the requirements or anything for them. And it just happened to be when they ran out of work for us to do and we're looking to downsize.
They miscalculated though, because they were trying to avoid paying unemployment because they were based in a state where the firing company pays it, but I live in a state where unemployment comes from a tax fund where the rate increases when someone makes a claim. The only other employee in my state? The CEO.
Interesting_Debate57@reddit
Start looking elsewhere.
Lopsided_Distance_17@reddit
Manager here, and wanted to share some insight. You said your points per sprint are low compared to the rest of the company. The manager does has cause for concern if this is a trend.
The points and point total doesn’t matter. That’s accurate. But when you compared points delivered per sprint, unless you are a junior, there needs to be a discussion behind why your velocity is lower. Are the tickets you take more technical? Are you a junior/mid at a company full of seniors? Do you have meetings that others don’t have?
The point of all of this being, if the rest of the company delivers 12-15 points a sprint while you deliver 5-8 points a sprint and everything else being equal, this points to an area of opportunity for improvement.
It sounds like your manager might be using something like the SPACE framework, but his wording of having you “defend” is stupid and passive aggressive.
You’d be wrong to think managers don’t use points to gauge efficiency of a team. In larger enterprises, the two benchmarks that get the most attention are DORA and SPACE. DORA measuring team efficiency/reliability/maintainability and SPACE that measures the individuals which focuses on Satisfaction and wellbeing, Perfomance, Activity (PRs, tests, etc), Collaboration and Communication, and Efficiency.
ppepperrpott@reddit
TL here. If someone gives vague/largely the same stand up update for a sprint and delivers one or two points, I'm going to have a conversation with my guy and ask how things are going.
I am then going to go away, verify what they have said, and decide if the circumstances are reasonable or unreasonable.
And then I'm going to come back and have a 2nd chat.
More often than not I'm going to think things are reasonable. Ticket meets definition of ready? Doubt it. Alternate flows and corner cases found during dev? Probably. NFRs? Maybe that 5 pointer has turned out to be more like a 13. Learning opportunity for the team during the retro to inspect and adapt our estimation approach.
But every now and then it isn't reasonable. Not often but it happens. 1 in 5 hires seem to be a superstar. 3 are alright. 1 is a disaster.
Is it reasonable to use story points as a performance metric? No. But as a smell or red flag to look closer at processes and performances? Sure.
StillEngineering1945@reddit
Review some tickets you worked on and bump points as turns out the work was much harder.
Unseen_Cream@reddit
I mean....how much code are you delivering?
OttoVonTralleis@reddit
Don’t estimate. You are engineer not a fortune teller.
NerdVT@reddit
He's an idiot...
I think the solution is obvious.
Aggressive_Ad_5454@reddit
Friggin’ fake scrum.
Your defense against this is to ransack the agile scripture to find where it says that story points are a planning tool and using them for tracking is harmful to the process and the team.
Next they’ll be giving bonuses for fixing bugs. If they do that, make friends with another member of your team and make sure you both have a lot of bugs to fix.
duane11583@reddit
then maybe they are not scoring during poker correctly.
if you find a non planned item go add it and the additional story points
satoryvape@reddit
Story points are just abstract numbers that represent story or task complexity. Do they treat 1 story point as day of work ?
martiangirlie@reddit
Point higher lol
edimaudo@reddit
hmm sounds good. I won't ask why they are using that metric in the first place and why your CTO is also having a conversation too.
I would suggest have a discussion with your manager to understand what they deem a quality story point with an example of a task. My guess is there was a conversation about productivity and a shift happened and you were not looped in. Based on this conversation you can then adjust how you assign story points.
Thoguth@reddit
Honestly the first word that came to m mind was "sandbag". If they want story points delivered, then give them what they want.
But I have also seen follow on to that, where the same managers who were pressuring for story point delivery know they've been gamed, and they're now challenging or shaming estimates for it... It makes things worse on a team.
Your manager seems like the type who went to business school because computer science was too hard. However, if one said that, asked me to "defend" then I would thank them for being so direct about it, and intrusive them to the wonderful world of mocking idiots who think that "individual velocity" is a thing.
I would engage my inner "Don Draper" and project a vision of a team that's focused on delivering not story points, but actual business value in the product, not as competitive, climbing, grasping and maybe backstabbing or undermining individuals, but as an aligned, supportive, mutually beneficial team.
Depending on his persuasion buttons, I might appeal to the scrum guide or the fact that I am one of the most trained and certified agile experts, or I might appeal to human factors, or to research on teaming for knowledge work, or to his own desire (I hope) for business value.
What changes for the business when the things we deliver are really valuable? Sales go up? Some production effort or other tasks get faster? That's the metric you want your team to care about, not how many Fake Estimation Points they're achieving as individuals. If you want story points for individuals you'll get that (and resentment, quality degradation, and burnout) but if you want the product to be better at what your product does, then get the team to care about your measure of what your product should make better. See if you can get a baseline or a dashboard for him. (Unfortunately, this would be a case of you doing his job, technical leadership, for him, but at least somebody would be, and in a fast growing company where he isn't going to feel threatened by someone good like that, it could be a positive for you. (Warning, if it's a slow growing company, government office or gov contact, he will feel threatened by you knowing this stuff, unless he's ... well, a way better leader than falling for the individual velocity trap makes me think he is. )
But however I have such a defense, by the end I would be looking for an enthusiastic thank you and a sincere recognition that he learned something and changed his view. If at the end of the conversation, you feel like he's still negotiating, that he's skeptical of your perspective or that he's politely tolerating you (or worse, still trying to debate it) I would stay looking for another job. This is also true if you have high confidence that you shouldn't engage to begin with because you already know he doesn't learn or that he thinks it's just a "leadership thing" that you don't get.
rfpels@reddit
Sorry. There is no defense against stupidity or idiocy.
Thoguth@reddit
Intellectual humility and curiosity can protect against it in oneself.
But someone with power over you and not smart, is very dangerous.
rfpels@reddit
Yes well. As Einstein mentioned there are two things that are infinite. The universe and stupidity. Although he doubted that about the universe.
Murky_Citron_1799@reddit
Once a team breaks the seal on metric chasing, I've never seen it recover. It never becomes sane again. At best it becomes an unspoken agreement and silent competition amongst peers to take the easiest most metric influencing work for themselves and avoid the non metric related work. It gets worse as documentation deteriorates and competent people move on to new jobs.
mcjohnalds45@reddit (OP)
I feel like they have opened pandoras box, (unless they opened it already with another developer).
Story points across the company will skyrocket as word gets out. It will be glorious.
illperipheral@reddit
huge red flag
HUGE
cmdnormandy@reddit
Story points do work at a high-level to measure velocity and capacity, but they're a terrible tool to measure individual productivity. Sorry to hear this but it sounds like you have to pad your points.
Advanced_Slice_4135@reddit
Oh my the ol padding game…
MaestroLLC@reddit
Tell him to read this article The Worst Programmer
Perfect-Campaign9551@reddit
Repeat after me:
Story points are not a productivity tool or metric. Story points are an estimation tool. That's it.
juwxso@reddit
Just make it higher, he might also be protecting you from some bullshit leadership decisions.
DagestanDefender@reddit
story posts don't mean anything, if they want more story points then just put more story points on the ticket
robk00@reddit
And here is the solution. Estimate more points. If something took more, update the points with a quick comment.
dinosaursrarr@reddit
Work for someone who isn't so dumb
PhatOofxD@reddit
Anyone using story points to measure is an idiot. This is your manager being dumb.
Just inflate the points slightly.
The idea with story points is to help roughly estimate how long it'll take to complete work to rely to laypeople. This is obviously useless if everyone inflates it.... Which they WILL do if it's used as a performance metric.
UncleSkippy@reddit
Story points are worthless. They are essentially arbitrary and can be gamified. Anybody using story points to gauge developer productivity, skill, or effectiveness has lost their mind. Full stop.
That said, you should play along, create an arms race, and raise your estimated points. Tell the CTO you have been consistently underestimating your points because you wanted to make yourself available to assist others on your team as needed, and you never included your documentation and removal of technical debt efforts in the point estimate. You will start doing so immediately.
Yes.
overzealous_dentist@reddit
Story points are an easy metric for an EM and tech lead to collaboratively gauge performance. The tech lead can tell if points are inflated, and the EM gets a quantifiable metric that lets them reward good output and notice when someone is doing much less than everyone else.
UncleSkippy@reddit
Unless the tech lead is head deep in the entire codebase and knows exactly what needs to happen for a feature to be fully "implemented", they they can not tell if the point are inflated or even accurate. There are too many factors that go into "implementation" that can be properly gauged ahead of time.
A quantifiable metric of what? What do you believe the intended metric of story points to be? What do they actually measure?
The problem is that all points are not created equal and trying to use story points as a unified measure of "something" is an exercise in futility. The people who hold on to them are trying to measure something that can't be measured.
After almost 3 decades in the industry, going through the ramp up of Agile, the haphazard early days scrum, the evolution of epic/sprint/story/etc through the years, and seeing who survived/thrived and who burned out, I do not believe that points provide anything truly useful and only serve to mask more important issues in the team.
overzealous_dentist@reddit
They are a rough estimate of whatever the team agrees it measures: time and complexity, typically.
Maybe you're thinking EMs want this to be a precise metric, but I've never seen it that way. What I have seen is a whole team agreeing that a ticket is a 1 pointer and someone consistently taking a week on 1 pointers - that is a quantifiable metric of effort that I can very easily point to. I cannot say that any single ticket should take X time, but I can very easily say that one person doing much less than everyone else reveals a problem (exactly what problem I would have to tease out separately).
MathmoKiwi@reddit
I feel that the people upset about it and saying "points prove nothing" are complaining that they don't give you the ability to tell about the 81st and 89th percentile workers, when that's not the purpose of it.
It's to identity the outliers, in particular those in the bottom decile. Those who need the most help to improve, or even to be kicked out of the company. identify
Miserable_Double2432@reddit
It’s not that either.
They’re supposed to be used to work out if a story is likely to be completed in the sprint given the team’s typical points completed per sprint.
It was explicitly designed not to be a measurement that can be used to compare performance between different teams, and using it as a personal performance metric is a really quick way to destroy even that, fairly suspect, utility.
MathmoKiwi@reddit
I know that, that this is the major usage for assigning points, but I'm talking about the specific context we're discussing here, of individual performances (such as OP's).
Unlike you I don't think it has zero utility here. As while it has basically zero utility when seeing fine grained performance comparisons, when it comes to identifying outliers it certainly is handy.
If everyone is doing 10pts or more sprint, except for one person who typically does just two or three points per sprint, then this case deserves more attention and answers found (the answers might be good, bad or neutral, but it's still worth investigating).
Miserable_Double2432@reddit
There are reasons why someone might be taking smaller stories, and for sure the manager or lead of the team should know why that is. But they should have already have known why that is in sprint planning
UncleSkippy@reddit
The point is (pun intended!) that there is no real "situation". If they underestimate their points, then the discussion is to boost their estimated points. If everyone else overestimates their points, then that "outlier" may actually be the baseline or even excelling and the under-performer may actually be one of the point leaders. Seen it happen.
Then people think the problem is with whoever is running the sprints, but unless they have absolute knowledge of all of the code in question, including both fine grained and systematic tech debt issues, then the point estimates are inaccurate from the start.
Point alignment is near impossible, and the errors accumulate over time to give you an exaggerated view of "velocity" or whatever other measure/metric you want to attach to it.
MathmoKiwi@reddit
What if they're not underestimating, what if it is clear that this outlier has been overestimating, should we still just ignore this and pretend as if we never noticed and discovered this info?
UncleSkippy@reddit
How do you know they are overestimating though?
That is the point. Without someone already knowing everything about the story/task/ticket/etc and knowing exactly what the points SHOULD be, you don't know if they are overestimating.
That is the issue. You don't know. And the measure or metric or whatever else you'd like to believe has meaning does not have meaning because there are too many variables (pun intended) at play. If you had a set of developers who were exactly the same with the same capabilities/skills/experience/whatever, then you at least have a consistent baseline to be able to deduce something. But that's not the real world.
The metric has no measurable or provable baseline standard so what are you measuring?
bwmat@reddit
"one person doing much less than everyone else"
Good luck accurately measuring that, go and fire the guy who slowly churns out high quality work in complex areas because the clique which LGTM's each other's balls of mud soars with their 'velocity'
SituationSoap@reddit
Serious question: do you think that everyone who works above your level in the corporate hierarchy is an incompetent idiot? Because that seems to be your perception, but I promise you that those people can in fact tell the difference between someone doing complicated, hard work slowly and someone doing simple, stupid work slowly.
killersquirel11@reddit
Story points can be a good metric, but they're a terrible measure
overzealous_dentist@reddit
See above, that's what the tech lead is for in the feedback cycle
PorkChop007@reddit
Or, as happened to me last year, they can be used as an excuse to put you in a PiP. Every manager knows that the story points are useless unless they can be used against you.
UncleSkippy@reddit
Suddenly everything become max points (whatever that may be for your org/dept/team). Now we're cooking. Look at that velocity!
xmBQWugdxjaA@reddit
UncleSkippy@reddit
MEEOOOOOOWWWWWW!!!!
pinkbutterfly22@reddit
This. Story points also don’t include the time I spent doing peer reviews or helped the team. So I stopped doing it. Next thing I know the manager was pissed nobody was picking up PRs without them naming specific people to do it =))))) What did you expect? You penalised me for the work I was doing outside of my ticket and story points.
grimr5@reddit
This
And look for another job, in earnest
narnach@reddit
This. The manager just gave OP incentive to go from team player to being maliciously compliant and selfish.
The team, product, and company will suffer from these incentives.
Du_ds@reddit
Being below average is bad? But if everyone was above average that’s not an average.
higeorge13@reddit
Just play the game
SubZane@reddit
Just estimate everything to 23 SP and in no time you will burn down +1000 SP per sprint!
AdHoc_ttv@reddit
Points should be estimated by the team, with a consensus on what the scope of the work is, regardless of who eventually picks it up. If the team thinks it's a simple task and it takes you a week, there's an issue. If your manager's only insight into your work is your velocity, there's another issue.
The goal isn't too do the most points possible; it's to have more predictability in your progress. I don't care whether your team's velocity is 10 or 30 - points are meaningless on their own. But if the team's average velocity is 30 points, and that average is consistent, I can make a good estimate of when a 60-point feature will be done.
On a team where pointing is done well, an outlier could be an indicator that you need to take a closer look. Seniors could be spending time teaching others, architecting, fixing problems, etc. Juniors could have not been properly on-boarded. Anyone could be slacking. But it's the trigger for a conversation, not a reason to let someone go. In a decent company, at least.
shifty303@reddit
I don't know why I had to sort by controversial to see the only good take out of hundreds of comments.
bruticuslee@reddit
If the story point estimate is by the same as the one doing the work, then the solution is obvious. I’ve seen teams where the team votes on the story points. Then the only way to inflate is by agreement of the whole team.
verb_name@reddit
Defense: "I've been under-pointing my stories. Other devs assign more points to similarly-complex stories. So my total work output is similar. It's just accounted differently. In the future, I will calibrate my story pointing to match the way other devs do it. We can solve this issue at a team level by having the team agree on story points for each task before the sprint starts."
Future action: Give your stories the maximum points you can get away with / game the system
lyth@reddit
Start looking for a new job that pays more. This is an incompetence warning flag in your line management and is unlikely to be the last dumb thing that happens.
Take your existing experience and sell it to someone else for more money.
ImSoCul@reddit
Put more points on your tickets. Half point stories can easily round to 1. Either people correct don't use it as a productivity metric or you play the game. This actually happened to me this week where my point total came in kinda low. My manager pointed that out but she's generally pretty nice and also knew this week in particular I was dealing with some production issues and worked like 60 hour week, so just bumped a 1 point story to 3 (accurate adjustment) then I cut some half pointers for other tasks that took me a few hours each but weren't really part of original planned tickets. Mild annoyance but all said and done took an extra 3 minutes out of my day
MoreRopePlease@reddit
This is a good thing to talk about: what is a story? What is a point?
When I spend half my day answering questions and pairing with a junior, there are no stories that reflect that. I can take a week to finish a 3 point story because I get pulled into meetings and design discussions and bug triage activities. And I take time to learn stuff or just think about the roadmap and what kind of problems we might have. None of this work is a story.
Imo, stories are "user stories" that reflect value to a user. "As a X I want to Y so that I can Z". There is no user or "value" to me designing something, writing most docs, pairing with a junior, talking to a 3rd party vendor about a bug report. Thus no story and no points. But I talk about these things at stand-up for visibility.
ImSoCul@reddit
exactly yeah. Internally I just use it as task prioritization/task sequencing. I have x,y,z that I want to work on in this order, y requires x to be complete, this is my best guess on how long it'll take, the confidence interval is 1 day +- 2 weeks to complete.
If tasks aren't being completed at a rate the manager is satisfied with that's a standalone problem and they may use points to justify. If everyone is on the same page, then we're back to accepting that points mean diddly squat in terms of when things get done and I'm happy
Alpheus2@reddit
Stop fighting the system. They want X story points per week, so make sure your plan for the week encompasses X points of work. Either you’re working too much to keep up or you’re underselling your vast accomplishments while being efficient.
Your manager is using story points to communicate that inconsitency (albeit clumsily)
Happy-Pianist5324@reddit
Increase the story points per story. Problem solved.
This career has gone to shit.
grunade47@reddit
what is a good or proper metric to measure developer performance?
serial_crusher@reddit
You should also change this practice. Like in all honesty you absolutely can't compare one dev's throughput to another if they're the one setting the initial valuation. Maybe I think 8 hours of my time is 4 points and you think 8 hours of your time is 8 points. We do the same task in the same time, but you've done twice as many points? Nah, you should be able to explain this flaw to your boss pretty clearly.
Bog the team down with "poker planning" sessions where you spend time having the whole team argue what the point value of each ticket will be. This will have the benefits of inflating estimates across the board AND slowing down the rest of your team's throughput, as they'll now be spending time in one more unnecesarry meeting.
serial_crusher@reddit
Every book on scrum will tell you story points aren't supposed to be used for individual level performance management. They're supposed to be a predictor for how much the team can get done in a given amount of time.
So, you work for an unreasonable boss and will now have to behave unreasonably. Time to start inflating your estimates.
nullbtb@reddit
It never ceases to amaze me how far people can bastardize agile.
Master-Guidance-2409@reddit
and suddenly every story grew 3 points larger :D.
story points are not suppose to capture performance because they were only ever indented to capture relative effort, complexity and risk WITHIN the same team working on similar tasks.
that said every single place I worked they are always used as KPI, so people always game them so they can rank higher.
this is why people hate agile, scrum. a lot of lip service but reality is grim and toxic.
tr14l@reddit
Estimate higher. You need to estimate the same way everyone else does. You're either literally not doing as much as everyone else, or you are estimating incorrectly.
FealsCBD@reddit
Estimate higher, problem solved. Sorry points are an imaginary unit, so bend it to your advantage.
jatmous@reddit
You have already been ranked and your manager is using the story points as justification.
MoreRopePlease@reddit
If you don't do this already, you should be keeping a "daily log" text document. Joplin is a great free note taking program.
In my log, I write down meetings "8:00-8:30 standup" as they actually happened. I write down helping people, starting a bread ticket, fighting with the bulls machine, helping another team, etc. My start and stop times, breaks and lunch.
This is a private record for me, so I remember things, but also so I can account for my time if anyone challenges me.
Mr_Loopers@reddit
Management will always use numbers as metrics. You just gotta game those numbers.
Reckless42@reddit
Easy. If you are scoping your own story points, just increase them. Game that system.
In an old job, we had a monthly bonus based on who closed a set amount of points. I was the one assigning stories. Guess who got their bonus every month.
Key-Alternative5387@reddit
Estimate story points higher since you're working the same hours as everyone else.
DrNoobz5000@reddit
Pump that number. Shit takes a 1? Nah, complexities make it a 3. What about that other 3? Shit, that actually needs to be a 5.
Inflate. And learn how to play the game, this shits about the money, nothing else.
nousernamesleft199@reddit
Just start overestimating
Rush_1_1@reddit
If your shitty boss is like this, just split stories into multiple stories that summed would be way higher than the original. Problem solved.
d0rkprincess@reddit
Estimate your stories to be more points?
BanaTibor@reddit
Is there a company wide well known policy about what a story point means? Maybe you are estimating badly and you price the stories cheap. If no such thing then this is complete madness!
dingdonghammahlong@reddit
If one of my stories takes longer than expected then I’ll just close the story at the end of the sprint, make a new one as a “follow-up” story saying that there was additional work that wasn’t in the initial point estimate and carry on.
When I started doing that, my manager said that my carryover metrics improved significantly and then I got promoted lol
Bubbly-Swan6275@reddit
inflate points lol
trcrtps@reddit
I'm constantly under measuring workload, severity, priority, etc.
That's why it should be the PO and Lead's job to quantify this stuff together.
rockyroads337@reddit
Joking: ask him if he knows about uncle job Serious: ask him if he has any recommendations or a simple way to track the complexity of the current sprint or project it’s illustrating
YetMoreSpaceDust@reddit
That's kind of what I do. When they start demanding daily status reports, I give them 10 pages of detail every day.
thadicalspreening@reddit
Your manager needs you to clock more points for their own metrics of their team’s performance. They probably dgaf about you. Increase the points on your damn tickets so that they look good.
denverdave23@reddit
I agree that you should be estimating higher. That said, if you want to argue that your work so far has been above expectations, argue on the value of your work.
Generally, you can think of performance in 4 buckets:
Impact - what did I deliver that helped the company? Usually, this is about money
Leadership - how did I drive other people's work? This can be as simple as helping clarify tickets, helping others, or participating in team meetings
Complexity/difficulty - what was particularly hard?
Scope - how wide ranging was your work? Did you affect other teams?
Story points are about impact, so talk about the value your tickets brought. Go through your tickets and say "ABC-1234 delivered the foobar project, which was important to the customer".
But, also talk about the rest. You were a force multiplier on your team by helping others, driving process, doing hard work, and working across the stack.
DigmonsDrill@reddit
At my software company everyone is above average.
Crafty_Hair_5419@reddit
If they judge you off of story points instead of solving business problems/delivering high quality code then that's the task. Work on story points instead of a product.
Inflate the estimates. Don't do a single thing without a ticket.
Then ask yourself if this is the type of place you want to work.
jungle@reddit
I'm a manager and your manager and CTO are full of shit. Story points are not for comparing teams or individuals. They are doing performance management wrong.
ewhim@reddit
Story points are not estimates - they're a measure of complexity and scope, aren't they?
Too many organizations equate points to effort days
TripleFreeErr@reddit
Ask them to define a story point then honestly explain how you have been underestimating them
techie2200@reddit
Depends on how open your manager is to communication, but in these scenarios it's usually a good time to have a conversation about where story points come from and what they mean.
If only the dev taking the ticket is pointing it, then you've got a problem where people misunderstand how points work, or they're under/overestimating complexity. You could very well be underestimating based on your team's usage of points.
The only place I've worked where we used story points as a metric, they were decided on by the team as a whole during refinement/sprint planning. Majority vote would give the point value and it was understood that was an estimate that could change. Generally, with the whole team deciding, you got more sane votes (potentially even more conservative votes) because the under/over estimates balanced out.
willBlockYouIfRude@reddit
Is this a trick question by them to check your knowledge or did your engineering management show they don’t understand what story points are?
livinginiowa20@reddit
If they’re truly comparing across multiple teams and having the dev who completes the story, then someone’s missing the idea. I have had to explain multiple times why comparing team velocities is a poor metric. However, looking at trend lines can help start a conversation. For instance did the velocity drop down: was it because of PTO, impediments, new work area where estimation of points was wrong, etc.
If you’re under pointing compared to your peers, calibrating to equivalent pointing would help. If I see one dev is way below others in points it’s a conversation starter to see what’s going on and how I can help.
Without knowing the context of the culture there it could be something looking to help but a poor choice of words with defend or it could be a toxic ranking process. But using the same scale as other devs would definitely help and less tell me how I’m measured I’ll tell you how I perform.
Individual-Praline20@reddit
Easy fix: give more points to your stories. Solved. 🤭🤷
prschorn@reddit
Start over estimating points, they mean nothing anyway
hippydipster@reddit
Have you asked them why they think your points are lower than average? Have you asked you why you think your points are lower than average?
There can be lots of reasons for it (you estimate lower; you do more careful work resulting in less rework and fewer bugs later; you're spending more time helping others, helping the team, or writing documentation; you're legitimately slow; you're slacking or they're working excessive hours).
Can't know what to do about it until you know the answers, and ideally they're understanding of the situation is the same as yours, and if it isn't, they need to be brought up to speed.
salamazmlekom@reddit
Then you're either slow or your story points estimates are too little. Defend yourself that your estimate was off and that the story you worked on was very complex (if it really was). Explain the reasons why it was so complex. Was the story unclear, did you need extra feedback, were you blocked by someone, etc.
But yeah using story points to measure performance ia trash although velocity is exactly that. See how much your team can achieve in one sprint.
In general it's wrong that you estimate stories by yourself. The whole team should estimate the story and the whole team should also disect the story into tasks.
farber72@reddit
Estimate hiiiiiiiii
Cool_Mushroom_Xyz@reddit
Your CTO has no idea what story points are.
They should be assigned by the whole team rather than the developer who pick up the ticket.
Also, considering they shouldn't represent time but complexity, compare and evaluate devs based on story points delivered is bonkers.
Next time increase the story points for your ticket and happy days, there is no point trying to have a conversation with your manager mate...
thekwoka@reddit
Obviously assign your cards more points.
Drawman101@reddit
Increase the points on your tickets then lol
Schedule_Left@reddit
Story points is and will always be a dumb measurement. But the non-dev sides always push for more stories, with less points. It's suppose to be a tool that helps us properly estimate work but they abuse it for these metrics.
Merridius2006@reddit
Too late thinking of estimating the points higher now, it would be obvious to them since you are under close supervision anyway. The only thing left to do is to grind harder and fight for your survival
broken-neurons@reddit
Estimate higher on average…
Acrobatic-Guess4973@reddit
What do they expect? Everyone can't be above average
oskaremil@reddit
Put more story points on the next tasks you estimate. That's how it is supposed to work.
nemeci@reddit
Over estimate story points.
SpriteyRedux@reddit
Story points are make-believe and they only exist to convince the C-level that you are "working hard enough". It's fools gold to get someone off your back. If you aren't completing enough story points, simply assign more story points to your tickets
Aromatic-Wait-6205@reddit
We had a similar situaiton before; management complained about the fact that our team was not getting enough story points done per sprint. So we just overestimated them. Never heard from management again. It's just another bullshit thing that is meant to distract us from our actual work.
Purple-Cap4457@reddit
change manager
thclark@reddit
You should estimate much higher story points. Problem solved. Hey, if they’re going to use a stupid metric, you can use a stupid solution ;)
gdinProgramator@reddit
You estimate your tasks for more story points. Simple as that.
Poker rounds are beautiful because all software engineers quietly support each other’s estimates, even if they bend the realistic expectationsz
gomihako_@reddit
double the story points lol
QueenAlucia@reddit
Your manager is being an idiot. I wouldn't fight it, say I'll fix it and just inflate my story points from now on...
Dziadzios@reddit
Start gaming the system. Estimate it as harder, split it into smaller tasks, create 1 story point tasks for one-liners, create separate tasks for implementation and unit testing. Then add tasks for code review. If you feel vindictive enough - make bugs to fix them later.
Malatok@reddit
You may want to start playing DND. Low story points is one thing, but combining with your low spirit?
Or even board games.
Adorable-Fault-5116@reddit
Since story points are arbitrary (numerically), if your arbitrary number is too low you could just 10x it? Like it doesn't change any of your processes.
lepapulematoleguau@reddit
Just inflate point estimate.
If I had a dollar for every manager that does not understand story points.
donquixote2u@reddit
If they are going to measure everything by the company average, are they going to fire half the dev teams every week?
Tohnmeister@reddit
Others have stated that you should inflate your points and that your manager is stupid. And while this all makes sense, it could also be that, regardless of how the measurement is done, management really thinks you're underperforming and just uses the story points as a metric to try to make it SMART.
Have you considered the option that you are underperforming? How do you rank against others in your view? What could you do to improve?
lllama@reddit
Nothing further to add.
mothzilla@reddit
Since you set the points, just inflate your point estimates. Done.
BTW, it's better (IMO) to have a team collectively agree on points for a story before a sprint starts. That way any developer can pick up a ticket and have a reasonable idea of the complexity involved.
Story points are by and for developers as a rough indicator of complexity. They are not a metric. Because some managers have tried to make them a metric, some teams use "TShirt sizes" as their complexity indicator.
But story points aside, generally it seems they're hinting you're not pulling your weight. I'd try to get a showcase feature ticketed off so you can easily rebuff their claims.
BoxingFan88@reddit
Try making every story you do an MVP
Then you deliver value every sprint instead of a stupid story point metric and you can demonstrate it
Nullify_Undefined@reddit
But what if the point estimation is done by the agreement from the whole team and still gets questioned by the PM for the low story points picked up?
st0rmblue@reddit
Break your stories even smaller and inflate the points.
Tervaaja@reddit
Just play the game. Create stories with high story points, but low work amount.
08148694@reddit
Developer productivity needs to be measured somehow
If by story points then it’s probably not a great idea to allow the developer working on the ticket to give the point number, or people will game the system as you allude to
Really the manager should not reveal the productivity criteria at all or people will game it
But yeah points, got commits, lines changed, PRs, number of PR comments, jots activity log, etc etc can all be used individually or as part of a formula to try to quantify dev productivity
There’s no perfect measure by any means, but managers need something and without data all they have is personal bias and vibes
rfpels@reddit
Story points are not a productivity metric. Period.
One-Savings8086@reddit
The problem seems to come from story points weight being incorrectly estimated when attributed to an issue. Also, it looks like there's an incomprehension of the reality of software engineering from your manager, thinking an issue's difficulty is invariant.
ruudrocks@reddit
Try to clarify with him understand where he’s coming from. Is it simply a matter of story points (in which case you have all the options raised in the other comments), or is there something else going on that he’s concerned about?
BEagle1984-@reddit
From now on, just estimate higher and ask for a raise as soon as the measured velocity increases.
Also, update your résumé because that doesn’t sound like a healthy place you’d want to stay in for long.
xmBQWugdxjaA@reddit
Find a better company.
I can't stand all the arguing about story points per task, story points per time, story points per sprint, etc.
Like people say AI dev is bad, but at least the LLM helps to actually write code instead of just arguing over that nonsense.
quantum-fitness@reddit
If youbare ballsy ask him how much he wants you to increase the estimate by.
If not just do it enough to go under the radar.
maxPowerUser@reddit
Points are a real headache, our managers are converting them to time. It's so bloody stupid. It just ends up with the team increasing the points.
gdvs@reddit
Increase your estimates.
If you don't think you'll not be able to explain what it's for and how it works, just work with the system. Don't try to fight it
jnhwdwd343@reddit
Just do a malicious compliance. Same amount of work, more story points
orangeowlelf@reddit
Re-point the tickets higher like everyone else 🤣
jontzbaker@reddit
This.
I delivered one hundred billion points just this last sprint!
Insert Doctor Evil gif here.
Instead of making an equivalence of points to simply the time spent working, multiply this by your hourly rate! Points are now money!
Go crazy!
programminghobbit@reddit
Quit. Your are working for imbeciles.
ALAS_POOR_YORICK_LOL@reddit
Start interviewing . And pad your estimates.
dragonsmilk@reddit
I always pad my estimates because why wouldn't I? I don't care about the company, obviously, they're a sociopathic profit-driven hedge-fund owned corporation. And what's worse, they're bad at it too (the making money part. The executives were the D+ / C students in high school).
Of course I pad my points then because it looks like I'm super productive all the time and then no one's on my ass.
Yes, anyone with a room temperature IQ can see an issue with the fact that each individual is reporting on their own productivity and so has massive incentive to lie. Thankfully, the bureaucratic idiocy is finally working in our favor for a change.
And yes it might make the true believers / innocent start to look unproductive by comparison. You just gotta get with the pad crowd is all. What are we NOT? It's a game here. Do we want to set a standard where we kill ourselves every sprint to make the corp a couple extra bucks? Or set the standard where it only APPEARS so while we work at a normal pace? Exactly.
ALAS_POOR_YORICK_LOL@reddit
I only pad them in environments where it matters.
In sane environments we use them as intended, like right now.
Incidentally right now they feel padded because my team is very inexperienced. But they just genuinely need that high of an estimate for things.
saspirstellaaaaaa@reddit
This guy has it all figured out.
Lgamezp@reddit
This. I always pad them
Gwolf4@reddit
Oh boy, absolutely everything can be used for ranking, everything, tell me how I know in my first lay off.
fizzydish@reddit
You have my sympathy. Estimates in general and story points in particular are the curse of software development. Measuring individual output in story points is insane. It’s a dimensionless unit made up on the spot at the point of least knowledge about the actual problem. The least terrible way to use them is to pick a rough number, let’s say 3 and work to break down all the stories to roughly the same size. Ideally a couple of days effort.
In your case, I’d take it as a signal that the management are clueless and make sure I broke every story into as many pieces as possible and give them all whatever number is ‘medium’ in your org. Estimation is fractal anyway so breaking them down into lots of pieces will naturally inflate the points, it makes you look good for really thinking through the problem and it’s easy to 3x or even 6x the points without making wildly high estimates.
Any-Woodpecker123@reddit
Just estimate them higher. Then when it takes you half the time to do them you’ll look like a god.
MadJackAPirate@reddit
solution: make higher estimates in SP
MathmoKiwi@reddit
Next week he'll be coming to you asking why you don't write more lines of code than the company average???
One-Set-1905@reddit
Just inflate the estimate per tickets. They measure you like a monkey, you will behave like a monkey.
Serious answer: move away from that KPI and start focusing on making measurable business impact.
Do not measure individual productivity, measure impact generated by the team that should work with focus on possibly a single thing. Individual performance must be evaluated instead qualitatively by the manager, peers and stakeholders.
Virtual_Stress3206@reddit
If I were to guess it would be that they've already decided you're not a good fit (for whatever reason real or imagined) for the job anymore and then, after talking with HR, they need to come up with a case with documentation of how many points you're doing versus how many points a dev "should" be doing per sprint. I would start looking at other roles just to be on the safe side so you have a bit of a headstart if it evolves into a PIP.
Imagine you had to fire someone and HR asked you to make a case to prove it and then put yourself in those shoes so you can better anticipate their actions and respond accordingly. It's hard to make a case with fuzzy things like points so you can game it and hit the goals you're given to give yourself more runway to get out.
bwmat@reddit
I would refuse to make up BS to die someone since I'm not trash
Good thing I never plan to be a manager
If you wanna fire someone you don't have to justify it with lies, just follow the termination conditions of the contract
sehrgut@reddit
As soon as story points become a management tool, they cease being a work-organizational tool. You now know that the SPs you set are not for helping you organize your work within your team, but are a management metric.
Start lowering your internal concept of how much work a single SP represents, and estimate accordingly. Your SP totals will rise, and the idiot managers will get what they want, which is of course Number Go Up.
Existing_Station9336@reddit
That's the root cause of all the problems. This leads to comparing apples and oranges when your manager sees estimates that are to him just numbers, so he feels like he can compare them, but in reality they shouldn't be compared as different people use different scales. You can either fix the root cause (the teams as a whole should be estimating together) which isn't easy as it's a team process and those are harder to change. You could work around it as others suggested - just inflate your own estimates.
ryanheartswingovers@reddit
Any job based on points is toxic. It’s not a board game.
yxhuvud@reddit
Raise your estimates and solve the issue that way.
parav01d89@reddit
Estimate higher, okay next question.
Appropriate-Fox-2347@reddit
One major problem here is that you did not know about your own goals and KPIs. This is a communication issue for management to fix. Goals and decent KPIs which are fair for everyone should be clear to everyone.
If you are not performing, you need to be honest with yourself. Underperforming creeps in. Sometimes for personal reasons (laziness, personal issues etc). Many times it's culture and management within the company. This is something you need to think about. If you're slacking off in a great (or even decent) company, then you need to fix this, and more often than not, being open and honest about this with your manager is a great place to start. If you're just not bothered because the company itself is toxic, I'd move on.
CasualEarl@reddit
Play the game. What your manager is saying is stupid.
Let me make this perfectly clear to you. You have a bad manager. Read that ten times. Now that we have taken that off the table and this is not a mental burden on you. You are not in the wrong.
Now the reality of what has happened, your manager just invited you to play a game of bullshit metrics and stupid Scrum tactics. Play the game. Treat it like a game and take your personal ethics out of the story points.
It's not you, it's the system that just got weaponized against you. Now you will weaponize to your benefit and just keep doing what you do. You just change the way you estimat, break work and move forward.
iComplainAbtVal@reddit
Overestimate the weights on your tasks
IGotSkills@reddit
Get a new job. This manager is a moron.
Salty-Custard-3931@reddit
Send him this: https://en.m.wikipedia.org/wiki/Goodhart%27s_law
LogicRaven_@reddit
Story points are not meant to compare teams, even less to compare developers. Also the mathematical definition of averge implies there will be multiple people below that.
On the short term, gaming story points can buy you more time. Maybe this story point based performance management nonsense will disappear after they understand it's limitations.
But if the company has financial problems or the org you work at is shrinking within the company, then more strange things could come. In that case, you should start looking even if you don't want to.
loganbootjak@reddit
Do what everyone else does and inflate your estimates. Story points are dumb, and it's typically hard to accurately estimate work without a good amount of refinement on the stories as well as technical input from the dev team.
marty_byrd_@reddit
I used to think story points were meaningless. Then I tried to make sure I was number one in story points every sprint. No invisible work. I’d write a card and move it to done if I had a side task. My career took off. I went from L4 to L6 in 2 1/2 years and to EM 3 months later. As EM I understood that story points while obviously not the whole story can be used as a quick reference point to your team what they are doing. If someone is bogged down spiraling on some task. If you’re consistently at the top it’s likely you are doing a lot of work. There are no negatives.
I also jumped 4 months later to a staff level role. So it worked out well for me. Give it a shot.
ThatFeelingIsBliss88@reddit
It sounds like story points work well if and only if everyone knows how to play the game. Like you said, if someone is going invisible work, and isn’t told to document all of that work, they will look bad compared to the rest of the company who knows how to game it. So in OP’s case, the manager should not be asking him to defend himself. The manager should first give him the benefit of the doubt and tell him to be more generous with the points and to try and document all the invisible work. Within reason of course.
bighappy1970@reddit
Double your points esimate ... or triple it...or more --- game the measurement.
Better yet, go work on a team that doesn't have a super crappy manager.
Your manager is an idiot, its not worth listening to whatever they have to say about story points.
Seriously, update your resume and go work somewhere that will invest in your skills.
Thin-Crust-Slice@reddit
This is a tactic used by inexperienced/lazy management, to build evidence they can use against someone.
I think this is the eye-opening moment when you see through the fog of whatever reality-distortion field management was using. IMO, do whatever you can to raise it and start looking elsewhere. Chances are, you'll get push back when you raise your story points, in which it means that management has targetted you. Even if they they back off, you'll never know if you've been marked by management.
Murky_Citron_1799@reddit
Aside from gaming the metrics, you could legitimately be getting less coding done than your teammates. Reasons could include that you are new to the team, or you are helping others understand their work, or you are spending more time reviewing code of others, or you are designing future work, etc.
Lgamezp@reddit
Story points dont measure that. They don't measure anything, thats why they cant be a metric.
Also, coding more≠working more.
ShenmeNamaeSollich@reddit
Our boss started similar BS w/a tool that tracks daily commits, pushes, PRs, merges, ticket closures, “velocity” trends, etc.
More little dots per category means you did more shit and are therefore a better developer and human being.
Result? Teeny tiny commits. One file per commit. Not squashing commits. Pushing after every commit. Smaller PRs. Pointless comments on PRs & uncritical PR approvals.
Some of those might be desirable, but people basically just game the system.
It’s also magically easier for the seniors who get to write new code for new projects to look like they get a lot of shit done, when in reality it’s more that they don’t ever have to waste hours/days chasing down obscure bugs in legacy apps only to ultimately make a single change to a single file and get basically no “credit.”
effectivescarequotes@reddit
Easy answer, increase your estimations. Storypoints were created for developers as a way to ball-park effort, but managers are stupid. They see a metric and they abuse it. If no one is challenging your points, move everything up. Your three point stories are five, your fives are eights, and your eights should be broken into smaller stories.
Harder answer, without showing any disdain, ask what the team considers a one-point story and how many points is reasonable for a developer in a given sprint. The correct answer is about 8. If they say anything larger, polish your resume.
ZukowskiHardware@reddit
I always over estimate. Also, using story points as “time” is completely wrong. No system I’ve ever heard of has been useful. The useful measure is how much of it is working in production. Idk what to tell you but I would get out of there.
YouShallNotStaff@reddit
Start looking for new work. If the cto thinks your performance is bad you don’t have a future here. And next time ask your manager in 1:1 how to stand out as an engineer
simo_go_aus@reddit
Obviously just start assigning inflated story points so you can be ahead of company average.
Honestly I'd be malicious. "10,000 story points, sorry need to up my average completion"
Northbank75@reddit
Game the system he doesn't understand.
warm_kitchenette@reddit
Everyone is (correctly) piling on to the inappropriate metrics chasing. That's the key problem. Your manager and CTO are somehow unaware that some people will inevitably be below any average, and also that this dumb metric can be gamified by anyone, so it's not predictive when the company punished people on the basis of it.
The first ask they have is that you "defend" yourself. So do that first. You'll show up, you'll be earnest. You'll find examples where you estimated 1 point when it should have been 3, .5 when it should have been 2, and so on. Just be prepared for the meeting.
You'll apologize for under-estimating, and pledge to do better. You will earnestly ask them for advice on estimation. One quick thing you can do before that meeting is to go through articles and videos by Steve McConnell on estimation. While I do agree with McConnell on most of his estimation, you're absorbing that background so you can have an informed discussion with them, not so you are free to disagree with them. Whatever they want is what they'll get, and you'll also treat them like experts, with things to teach about estimation.
Secondly, look for other reasons that might have led to over-promising and under-delivering, especially if they involved time away from work. If there were personal reasons for you not working a solid work week during whatever period they're evaluating, don't mention them at all. There's no reason to assume they're acting on good faith. Don't put thoughts in their head.
However, if there were work reasons for you to under-deliver, you'll probably want to bring those up. You were doing extra support because of that incident or because Harry and Chen were away that whole sprint and you had to help the other team architect their calls to your group's API. You were writing up documentation or mentoring a new person. Your machine completely died, or the dev/staging environment failed in a way that affected you more than others. You had the mandatory half-week seminar on how to shuck oysters in a HIPAA compliant way, or whatever took up your dev time.
You don't want to sound like you're throwing out excuses. You're just calming recounting reasons why fingers weren't on keyboards. Most importantly, you're really recounting all the reasons why you're a valuable part of the team: because of the dev environment you fixed, because of the docs or mentoring, because you pitched in to do support. Whatever is true.
Flashy-Bus1663@reddit
Inflation 🌈🐻
manyChoices@reddit
If they're going to be idiots then use story point inflation to get slightly above average. (3 becomes 5, a few 5s become 8s) Not too much or they'll think something is up.
They'll feel better about you while patting themselves on the back that they were able to "coach" you into performing better.
Then find a new job so you no longer have to work with idiots.
Source: EM who had to tell their team to do this to protect themselves when idiots in power behaved this way.
National_Count_4916@reddit
As a lead I once had a (new) manager come to me and say he wanted to put 40 points on the board because the team wasn’t doing enough and he thought this would get them to see how capable they were
In my head I went lol nope (this was about 4x what they were barely doing). They had a productivity problem but raising the targets instead of supporting them to be successful wasn’t the way
Do have a conversation about what ideal productivity looks like, and map it to points
Djelimon@reddit
The defense is to raise points
Hot-Claim-501@reddit
Inflate not only points but lines counts in MRs as well. This is another stupid metric they can come to. Be proactive !
asromafanisme@reddit
Just jack up the story points next time. For your defense, you can say that you underestimate the effort, and you're working on that topic to improve.
Repulsive_Constant90@reddit
Just create bunch of story points then.
shifty_lifty_doodah@reddit
Quit
AngusAlThor@reddit
Just pump your own story points up; If no one checks them, then it is up to you.
Dry_Atmosphere_8029@reddit
Either your story points are inaccurate with zero assumptions or real work accuracy. Or your velocity sucks - which one is it?
dpidk415@reddit
Hmm, this is sorta code red for you. They’re very clearly saying your output is below others. If you can’t defend it, you might be on a path toward the door.
If they pulled up PRs or your peers, how would you stack up?
Speak with your manager about how to course correct. If the issue is story points not reflecting the output, then work with them to fix it. If you’re not pulling your weight, you’re going to have to take on more tasks.
GL
Dear_Philosopher_@reddit
Dont work for startups
Cool_As_Your_Dad@reddit
Yea crazy to go on story points.
Just game the system now.
ydmatos@reddit
Do more points
Constant-Listen834@reddit
this is literally the answer
aa-b@reddit
Do you have a story point estimation guide like https://teamhood.com/agile/story-point-estimation-table/? Simple answer is to start defining stories in terms of effort instead of outcome, and don't punish yourself if acceptance criteria are not met inside a sprint.
So if a story is 90% done, close it and add a followup story instead of moving the whole thing to the next sprint.
IProgramSoftware@reddit
Well always take a 13 then
Legatomaster@reddit
Always pad your estimates heavily.