Hacker News Reader

What the hell is a required weekly point total?

It's the value of all the issues you complete in a sprint. See: Agile process, Scrum, etc.

It's stupid.

It may be stupid if you don't understand it or apply it incorrectly. There is no "agile process" that defines "required weekly points".

It's most likely in the context of an agile methodology - "a time-boxed iteration of a continuous development cycle. Within a Sprint, planned amount of work has to be completed by the team and made ready for review."

The planned amount of work is established via a number of tickets, each containing a point value in vague terms of difficulty/time. As you complete these tickets you tally up points. While this system is quite efficient, I'm also starting to have doubts as it could tend to lead towards gamification. Analyzed from a narrow scope/from manager or director's perspective, can lead to simple conclusions about the employee. For example, John is a better worker than Mary because for the past 5 sprints, John's point total was 130 while Mary's was only 100.

That sounds seriously like agile gone wrong. If the team isn't able to complete the amount of points in the sprint, there should be reflection: why not? Maybe we estimated the amount of work wrong? Maybe the amount of points was already set up by "crunch standards", not normal standards. Btw. who does the estimation? In our team, it's us, the developers.

I've yet to see examples of "agile gone right" outside of folklore.

I work with multiple groups at any given time and all of them end up following many of these patterns. Through one proxy metric or another, agile systems become bad accounting and metric systems that are used to pressure developers to the point of burn out and or leaving.

For management, the goal is to push more efficiently from a fixed salary. From their misguided perspective, they're already paying you $100-200k+, so they own all of your time. The more they can get you to do over 8 hours, the less they're paying per unit (hour) of labor. This leads to high turnover, burnout, poor products, and is ultimatelt passing costs off to employees.

At some point, for many, time investment vs compensation can even out to working a fulltime and decent full-time and part time job (12 hours a day). The employer has managed to disguise this through all sorts of deceptive means. The employer may be ignorant that fact, they may (genuinely) think they're just pushing you to work a full 8 hours or so, but it's more common than people seem to want to admit. And ego in software development and widespread imposter syndrome for newer developers just perpetuate this problem.

New developers won't admit when a request is absurd, they assume they're slow and pickup the slack. They also are trying to gain entry to the market so they're willing to sacrifice their time in hopes to jump ship for a less toxic environment with higher comp to time ratio. "This is just temporary." Ultimately, that mentality creates an expectation and experience only buys you so much efficiency in certain situations. Those new developers provide positive reinforcement to business managers that "this is the way."

As that happens at more and more enviornments, work to life balances become toxic at more and more places and the end result is, those new developers may never get a chance to escape that toxic balance because they've enabled it, everywhere, through fierce competition of ego.

I learned this at my first job when a very senior (nearly retired) developer working in development since the punch card era seemed to only be producing a little more than I could in a day. I thought, well he must be barely working, lazy or incompetent because I'm a newbie and not too far behind him. "This guy supposedly helped contribite to the development of quantum theory, write some of the first computer simulations for this, and friends with nobel prize winners? What a sham, his skills must be so dated!"

So for awhile, I started churning out more progress than him but he never changed his pace. At some point I realized I was investing a lot of extra time for no apparent reason. I didn't get paid more. I got some "brownie points" but ultimately, I realized I was undercutting my manager and mentor by using my free time and at the same time, creating an expectation of my production rate that required more than 8 hours of work. I was sprinting in a marathon and only harming myself by trying to be competitive and show I was as good or better as this relic developer. It turns, out I was just unwise, and he was light years ahead of me at setting realistic expectations. Through the rest of my career I realized he had created the most realisticand accurate time estimates for development timelines I've encountered and created a work environment that was well balanced for everyone and kept his boss happy, all while no one was stagnant and still developing professsionally.

To add to this, using numbers is a common mistake for agile estimation. Better to use things like t-shirt sizes. The problem is estimates aren’t associative, but making them numbers geatly increases the odds that someone will try to add them together anyways. And the biggest mistake is to give the numbers units of time. An expectation that a 3 point story will take X hours is particularly bad as that reporting gets higher in the org chart, since the only focus will tend to be on the translated time.

Your gamification example and using agile velocity to rank individuals is it’s own dark pattern too. The team should be the unit when doing agile, everyone has their strengths and weaknesses, but ranking due to to ticket closes is lazy, and so many factors that increase team velocity. For instance just having someone on the team who can tackle the bigger ticket can hugely improve team performace, as can having someone good at closing lots of little tickets. Neither is necessarily more important to the team, but having them both can be really effective.

I can tell you from experience that point quotas however it’s measured is its own mistake, that will lead to substandard teams. I was lucky enough to have enough clout at a previous job that every time management tried to go this route I was able to push back long enough that general productivity had a chance to improve without this sword of damacles causing morale problems.

And if you work for a place that has billable hours, I’m sorry. Much of my advice, while applicable, may be trumped by needs around client billing. Hopefully you make enough money to deal with this kind of stress...

What happens when t-shirt sizes end up mapped to the same point values when evaluation time comes around? My current company is in a belt tightening cycle, and recently introduced stack ranking. Implicit metrics are still metrics, even if they're lazy.

Yeah, this has a tendency to happen, it's sort of the constant fight. You can really only fight it with metrics, you can sort of start to show that 3tiny+1med tends to be equivalent to 1 large tends to be equivalent to 5small, or whatever. At the end of the day, you're trying to make it as hard as possible to simply add numbers. People will naturally try to map these things to ordinal numbers, and it's important to sort of keep a light constant pressure to prevent this the further away from the team you go. You need to start by training your team and your PMs and your manager to avoid this as much as possible. It's their job to train their stake holders and bosses in turn. I can tell you from experience that it's an incredible amount of effort, but the benefits are really worth it. Having a team with space to be effective is a magical place to be. I still mourn needing to leave that team and organization.

Oh, and sorry about stack ranking. It can be the beginning of the end. Job market is bad right now. But it might be wise to look at postings, and see what techs you want to brush up on. I’ve seen stack ranking destroy orgs, especially since good teams tend to disproportionally attract good talent. But management never believes that your whole team is above average.

I fortunately have had my eye on the exit for a while, and am set to leave soon. The rest of my current team isn't so lucky.

In the spirit of these things, point values are for individual teams to help benchmark their own rate, and not meant for comparison across teams using different point references.

If there is company-wide point tallying, it will lead to gaming and point inflation -- at which point the benefit of rate estimation will be lost.

We run psuedo agile where you are required to close a given number of points each week. Each ticket is given a point value based on percieved complexity. Point total on closed tickets have too meet or exceed weekly requirement. Not a good time.

But story points are estimates. Estimates are never set in stone. I’ve successfully argued this many times in the past. Software development is too complex for estimates to be always correct.

Anyway don’t mean to preach, sounds like you’re having a tough time. Sorry about that hope it gets better

The natural conclusion of "you can't manage what you don't measure" ideology.

Some software shops, unfortunately, take their "Agile" a little too seriously. They end up treating developers like assembly-line workers with a quota to meet. Those burndown charts become a very important metric that managers can show their managers, etc.

One could call it metrics-driven development.

Someone watched Black Mirror and thought the show had some good ideas.

I hear you on that. Try to find little ways to help yourself.

A few suggestions, no idea if they'll work for you but maybe you find something in the list or one of them gives you an idea.

1. Meditation. Even if it's just 5 minutes a day. Most of the apps have free trials. I really like 10% Happier but all of them are reasonably good.

2. Journal. This is a good way to just snapshot your feelings and stuff. I'd suggest writing it on paper as opposed to using some form of technology. Take 5 minutes a day and write.

3. Go for a walk, maybe with the kids? Time with the kids and good for your health. Even if it's a short walk, it's something.

4. Try to find one simple way to improve each meal you eat. Can you reduce the salt? Can you swap in something healthier for that unhealthy bit?

5. Find a lightweight hobby you can do a little bit each day. Maybe it's building lego, maybe it's reading a book for fun (and not work), etc.

6. Get enough sleep... this is important. Sleep is vital and without enough of it you just set yourself further back.

I know you said time is tight, but the thing is you have to try to make time for things will get worse. Start with 5 minutes a day. Most people can find 5 minutes in their day.

Good luck. I hope you find some small ways to improve your life. Ultimately for me not working that job was better for me. This is a terrible economy though so I get that you feel stuck. When it starts to improve, take the time to find something that's better for you.

Why are you point commitments from planning so high? Sounds like they are 25% - 30% higher than they should be.

They are. I don't get to choose my point commitment. It's set for every one. Turn over is surprisingly high...

At least I Scrum, as I understand it, the commitment should be chosen by reflecting it to past velocity. If that velocity is achieved only by crunching and overworking, that's a problem that needs to be addressed. If it can't be reasonably addressed, that's a sign of a toxic workplace.

Time to start padding out your point estimates for things. It's not even a lie: if you're working more than the 8 hours you're supposed to in a day, you're underestimating the complexity of things, which is actually the real lie.

Some of this comes from team dynamics: you all have to together commit to not working every night to avoid burnout and competing with one another.

Wish I could. More senior engineers argue for lower point totals. Environment is just designed to squeeze the maximum amount of time out of engineers.

Even as a well-paid, salaried software engineer, there's a moderate chance that they're still obligated to give you overtime pay (at least in CA -- heavily depends on your jurisdiction), especially if your job is implementing a series of small stories that are completely designed by somebody else and especially if there isn't enough leeway to take a little time to learn about the thing you're coding. You might consider talking to a lawyer or some kind of workers advocate. A year of back-paid overtime can go a long way toward weathering a recession ;)

"Required weekly point total" sounds like a nightmare. I'm guessing you are a software dev? Are you a non-remote worker in SF/Silicon Valley? If not, I'd suggest looking for a change in employment. The job market is messed up right now, but startups have the money and desire to grow, and are adjusting to more full-remote workers.

Can you overestimate your story points a little?

That can only work for a short time. There is a feedback loop at play here and it will seek a stable equilibrium. The organization needs to solve its internal problem.

The move from estimates to story points is actually a part of this compensation already, companies pretend that story points are about giving the developers more freedom to our faces, but actually they are about taking our estimate that something can be done in a week and removing the word “week” so that it can be estimated as a couple days’ work instead by our supervisors.

The fundamental process is already, at most agile shops I have seen,

- I the dev am going to build in some unconscious safety buffer by giving an estimate that I'm 90% or 95% confident in,

- I am going to give myself more safety buffer consciously by doubling or tripling that estimate when I communicate it to my boss,

- my boss is going to give us even more safety buffer by lumping together all of our tasks and then adding another 50% of time to that

- and then they are going to give it to their non-technical bosses, who are going to survey this estimate for the project and insist that it needs to be done in 25% less time, it is urgent, we need it sooner than that.

Story points allow a bunch of this to happen without explicitly contradicting anyone. But the basic problems is much more fundamental and it is that management and engineering are being phrased as having opposed interests. This is a basic failure in any negotiation: once it turns into a zero-sum game, everybody loses. In turn, there is a set of books that pinpoint say deeper problem, as being focused on controlling costs rather than driving revenues—which we see in these story point quotas, gotta make sure you get your money's worth from the dev team.

> working 12 hour days just trying to make sure I hit the required weekly point total

This seems to be against the spirit of most systems. If a company has a "required weekly point total" it seems it would be a race to the bottom as developers start inflating point values. Also, if "required weekly point total" needs to go up over time, and it isnt through improved methods, then that will also lead to point inflation.

At that point, the points mean nothing because you can either use them to honestly estimate projects, or you can weaponize them to churn developers (in which case you cant use them to estimate any longer.)

> Completely fried, working 12 hour days just trying to make sure I hit the required weekly point total. Cant spend any time getting better as all my time is spent just trying to survive. Take time to properly learn means my points drop and I'm fired in the middle a recession. I do nothing but sit at my desk trying to close tickets. Stress level is through the roof, gained 20 pounds, no time with the kids.

Name the company so that no one else suffers needlessly by tying their ability to provide for their family to said employer. That sounds like a terrible situation for anyone to be in.