Manager setting points targets
Posted by procrastinatorluke@reddit | ExperiencedDevs | View on Reddit | 38 comments
I’m part of a 5-person dev team:
- Two devs with 2–3+ years on the team
- Me: \~10 months on the team, 3+ years at the company
- Two newer devs (less than a year at the company)
Our manager (also sub-1 year at the company) recently started suggesting I should be delivering 2x the story points I currently do per sprint. For context, I usually land around x points, and the team typically plans for about 6x total per sprint.
That expectation doesn’t quite add up. Most sprints follow the same pattern: everyone starts with their assigned tickets, there's a rush to finish them, and then a small number of unassigned tickets are left. But there's strong hesitation around pulling more in mid-sprint due to fear of missing deadlines.
On top of that, I’m the go-to person for one of the newer devs, which means I spend time helping them get unstuck while handling my own work. That support role usually costs me the chance to grab second-wave tickets, so my point output ends up capped.
I’m starting to worry that this is going to skew how my manager evaluates me and might limit my future growth at the company. I’m not sure whether I should push back, adjust my approach, or just ride it out.
Has anyone here dealt with a similar situation? Would appreciate any perspective.
3May@reddit
You need to ask this whoever why they think you should be delivering twice as many points. Where did that idea originate, what's the measurement, etc. Ask about your real code quality in that conversation. Try to draw the picture that 2x points might equal 2x QA issues.
angrynoah@reddit
Story points are not scalar values and cannot be added together. Anyone that starts down that road ends up in Hell no matter their intentions.
ActuallyBananaMan@reddit
Isn't the point that velocity is the sum of story points delivered and a sprint has a size based on velocity? Which means that story points must be scalar values.
And yet then people say story points are an estimate of complexity, not of size or time.
It's almost like the whole thing is just technobabble for project managers and doesn't mean a damn.
angrynoah@reddit
Exactly.
Here's another way to look at it. Many folks will claim that story points and t-shirt sizing are equivalent. So an S story is a 1, M is 2 (or is it 3?), etc. What's S+S+M+S+L then? It's meaningless, you can't evaluate that. You can count them but not sum them.
But if I can't meaningfully sum t-shirts, and story points are equivalent to t-shirts, how is it valid to sum story points? It's not!
pavilionaire2022@reddit
Probably read some article about how devs are supposed to deliver 2x the tickets with AI.
Can't your team just double all your estimates? Does your manager have a clue what reasonable estimates are for tasks?
Puggravy@reddit
You need to start estimating tickets higher.
fuckoholic@reddit
Easy. During the next sprint planning estimated by the same factor of 2x.
Empty_Geologist9645@reddit
Just deliver the thing. Make a ticket for all your stuff and add the points to them as well.
drumDev29@reddit
I always wanted to be a professional ticket filler outer
penguindev@reddit
Tell your manager to read the book 'peopleware'.
Ugiwa@reddit
Just double the estimations.. I'm sorry but is your boss okay in the brain?
Alone-Low3274@reddit
Stop helping others, do the easy stuff with lot of points for not much work, overestimate stuff. Can't fix stupid, play their dumb game.
abandonplanetearth@reddit
This is great advice for anyone who wants to hate their job.
PoopsCodeAllTheTime@reddit
This is correct and it's also what I mentioned in my other comment: hunger games.
drnullpointer@reddit
Any time I see a team that is preoccupied with story points I already know the team is in trouble.
Story points are meant to be an estimation tool, not a productivity measurement.
They can't function as a productivity measurement because of the simple fact that any measurement that is used for measuring productivity becomes a target and when measurements become a target they stop performing their original function and become hostages to various types of games by employees and management.
It is management 101.
Your management seems to be utterly confused about this whole idea, which is unfortunately on par with what I am observing.
KronktheKronk@reddit
You have to point out all the non-ticket work you do every sprint and get them to understand that PR reviews, mentorship, pair programming, unplanned work, bug fixes, etc all fall on your plate as the lead. At the end of the day, does your boss trust you? If he does, and you're working diligently, then he needs to accept that the changes that need to happen to enable you to do more implementation work are functional changes to the way the group works, not just more effort on your part.
procrastinatorluke@reddit (OP)
Not sure if it's unclear in the post (will edit anyway) or my reading comprehension is shot but I'm not the lead, I've ended up as the go-to for that jr as a result of geography (team is remote and we're in the same time zone) as well as experience in the company, but that doesn't mean I'm not doing some that work regardless
mechkbfan@reddit
Need to make it visible to your manager in a way they'll understand
One way is to make it painful for them.
Everytime someone asks them for help, tell them to confirm with manager and that you'll need to remove story point(s) from sprint to do so.
koreth@reddit
Or 3. The people asking for help, faced with the prospect of having to inform the manager that they’re stuck without you, suddenly realize that they had the power to figure it out for themselves all along.
mechkbfan@reddit
Now that's wishful thinking but agreed
LookAtThisFnGuy@reddit
That's real experience talking
notAGreatIdeaForName@reddit
Easy: Just estimate the double points
Shazvox@reddit
Easy. Double your storypoint estimation during refinement. Crap data for crap bosses.
Suepahfly@reddit
Your manager wants higher out put. Probably because upper management told him so.
Find out what is needed for your teams to increase output and discuss this with you manager. A racecar retrospective might help here.
Instead of adhoc helping them out every time they get stuck make a growth plan for that person so they can fix their own issues. It looks they are one of the reasons you cannot increase the teams output.
You could also have knowledge sharing sessions. Keep them short, to the point and succinct. We limit those to 45 minutes and actually have a story on the board so it can be estimated and assigned to someone.
aroras@reddit
Why would he believe you can do twice as many points? What’s his basis for that conclusion? Are the other two experienced devs outpacing you?
birdparty44@reddit
I try to aboid companies with too much management. Especially those who were never doing the daily development grind.
PoopsCodeAllTheTime@reddit
This is no different from a manager telling you how many "point" you should vote for your story. It's not logical, they just woke up one day and decided they'll pressure you to the limit until you either do the work of two people or burn out and give them a reason to fire you.
ZCEyPFOYr0MWyHDQJZO4@reddit
You need to bump up story points across the board so your team's "velocity" is increasing. Then you need to require every interaction to have a ticket/issue.
dreamingwell@reddit
There are three realities of every job… what, when, and how much. You tell me two, I’ll tell you the third. If you tell me all three, then the repercussions are on you.
light-triad@reddit
If your manager is going to use story points as a performance management tool, and you're spending time helping your should create Jira tickets for that work.
Fair_Atmosphere_5185@reddit
Just increase the story points per ticket. Stupid asks get stupid responses.
hojimbo@reddit
This is the right answer. What the manager is trying to do (use story points as performance metrics) is asinine and breaks their intended purpose. He wants to play games, then what he’s turned it into is a game.
Fair_Atmosphere_5185@reddit
"When a measure becomes a target, it ceases to be a good measure"
JaneGoodallVS@reddit
How much control do you have over estimates? Do they look at Goodhart's Law-able velocity metrics?
procrastinatorluke@reddit (OP)
not a lot of control, usual team votes and settles around a majority, I fear that's already started to happen with how reluctant we are to pull in extra work
JaneGoodallVS@reddit
How friendly are you with your team? Can you guys collude to fluff estimates? Would your manger notice and if so, would he care?
PoopsCodeAllTheTime@reddit
I would like to see someone offer a solution because tbh this is a huge red flag to me:
Because team will set scores as a group, this is already nonsense as everyone underestimates and then individual engineers have to carry the weight o their shoulders. But not only that: you are now getting point-evaluated against your peers. This is hunger games for picking the best tasks while leaving the bad tasks to someone else, so they are eaten by the zombie managers.
SimonTheRockJohnson_@reddit
Your manager is trying to show "impact" by using measures as targets. The only universal way to deal with this is to convince him of a different understanding of his impact problem and execute on a solution to that impact problem. How realistic this is, is unknowable with the information you've given.
What usually happens is that teams that survive this because the problem isn't "real", will likely naturally just devalue what a point means and simply point things higher over time, you can accelerate that process by pushing it with your other devs.
The "realness" of the problem is really if it's a budget / economy of scale problem and the manager's bosses have told him that if he doesn't do it everyone is getting fired not just him, but even that is can simply be perception management.
In short, this is the "bad" side of scrum, that it's often picked because bad managers feel that they can "add something" in this system whether they know/admit that it's fake based on arbitrary metrics or not.