7 ms·

Going through this now. Completely fried, working 12 hour days just trying to make sure I hit the required weekly point total. Cant spend any time getting bette

Going through this now. 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. On top of this, little kids are home so productivity is hard. 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. It is not great.

kyberias 6y ago
What the hell is a required weekly point total?
- metalliqaz 6y ago
  It's the value of all the issues you complete in a sprint. See: Agile process, Scrum, etc. It's stupid.
  - kyberias 6y ago
    It may be stupid if you don't understand it or apply it incorrectly. There is no "agile process" that defines "required weekly points".
- futureproofd 6y ago
  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.
  - GolDDranks 6y ago
    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.
    - Frost1x 6y ago
      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.
- wonderwonder 6y ago
  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.
  - tra3 6y ago
    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
- closeparen 6y ago
  The natural conclusion of "you can't manage what you don't measure" ideology.
- noarchy 6y ago
  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.
- heavyset_go 6y ago
  Someone watched Black Mirror and thought the show had some good ideas.
selykg 6y ago
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.
kaiju0 6y ago
Why are you point commitments from planning so high? Sounds like they are 25% - 30% higher than they should be.
- wonderwonder 6y ago
  They are. I don't get to choose my point commitment. It's set for every one. Turn over is surprisingly high...
  - GolDDranks 6y ago
    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.
core-questions 6y ago
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.
- wonderwonder 6y ago
  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.
  - hansvm 6y ago
    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 ;)
strbean 6y ago
"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.
potta_coffee 6y ago
Can you overestimate your story points a little?
- crdrost 6y ago
  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.
TuringNYC 6y ago
> 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.)
heavyset_go 6y ago
> 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.

kyberias 6y ago

What the hell is a required weekly point total?

metalliqaz 6y ago
It's the value of all the issues you complete in a sprint. See: Agile process, Scrum, etc. It's stupid.
- kyberias 6y ago
  It may be stupid if you don't understand it or apply it incorrectly. There is no "agile process" that defines "required weekly points".
futureproofd 6y ago
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.
- GolDDranks 6y ago
  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.
  - Frost1x 6y ago
    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.
wonderwonder 6y ago
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.
- tra3 6y ago
  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
closeparen 6y ago
The natural conclusion of "you can't manage what you don't measure" ideology.
noarchy 6y ago
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.
heavyset_go 6y ago
Someone watched Black Mirror and thought the show had some good ideas.

selykg 6y ago

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.

kaiju0 6y ago

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

wonderwonder 6y ago
They are. I don't get to choose my point commitment. It's set for every one. Turn over is surprisingly high...
- GolDDranks 6y ago
  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.

core-questions 6y ago

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.

wonderwonder 6y ago
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.
- hansvm 6y ago
  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 ;)

strbean 6y ago

"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.

potta_coffee 6y ago

Can you overestimate your story points a little?

crdrost 6y ago
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.

TuringNYC 6y ago

> 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.)

heavyset_go 6y ago

> 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.