How do you deal with a team that uses "Agile" and equates story points to hours?

Profile picture
Anonymous User at Taro Community3 months ago

And not only equates story points to hours but is constantly looking at your story points and tries to lower them in an effort to push more work to you. I feel like I'm an assembly line worker instead of a software engineer that solves problems. Have any of you experienced anything similar?

22 Likes
1.8K Views
4 Comments

Discussion

(4 comments)
  • Profile picture
    Android Engineer @ Robinhood
    3 months ago

    My previous company went though a similar phase when we went through an agile transformation: I ended up just saying "42069 story points" every time an estimate was needed from me. Eventually, people just caught on and left it alone. This definitely won't work for your use case, but maybe you can overestimate your story points for each task to bump the number higher. Or if you're feeling risky and want to throw some satire in the mix, you can give yourself 1 single simple task (like a copy change) and assign it a large amount of story points (like 50000).

    10 Likes
  • Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    3 months ago

    I hate these kinds of teams - This was my life earlier in career. Ironically, any engineering organization that is very gung ho about being "agile" is almost certainly not agile and is actually just steeped in JIRA politics and bureaucracy. The companies with the best engineering culture tend to give their engineers a lot of flexibility and autonomy: This is a big reason why Big Tech companies are so renowned and successful.

    As Jonathan mentioned, I recommend shielding yourself by adding a lot of buffer to tasks (I think +50% is a good range, so turn 2 weeks into 3 week ones for example). You want to add a good amount of buffer anyways to help guarantee code quality, and this buffer also lets you negotiate down when people come knocking to shave off your story points.

    I talk in-depth about estimating tasks well here: "How can I get better at estimating long-term projects?"

    If stakeholders are too aggressive pushing down your estimates to the point of insane austerity, firmly (but politely) push back using the tactics here: "What are good strategies to push back when the deadline is not realistic?"

    Another option is to see if you can change the overall process to be more engineer-friendly. It's not likely to succeed, but it's worth trying. When it comes to actually conducting an engineering team effectively (i.e. empowering them), I recommend the principles here: "How do I optimize my sacred hour at work?"

    And of course, if it gets too bad, try to switch teams/companies. Easier said than done of course (especially in this economy), but at the end of the day, no job is worth your mental health. Here's our masterclass on how to find a genuinely good team: [Masterclass] How To Choose A Good Company And Team As A Software Engineer

    23 Likes
  • Profile picture
    Head of Engineering at Capgemini
    3 months ago

    This type of failure mode usually occurs when someone in charge of the project is solely responsible for "project management" tasks (basically cracking the whip and coordination) and usually detached from the (engineering) domain itself. If this is the case, I'd suggest bringing it up as a topic in a 1-1 with someone more senior in your engineering org, which usually is your manager/skip level. Otherwise, it's worth examining the underlying motivations/incentives of the person insisting on this (it's quite rare from my experience that someone more senior on the engineering ladder like a staff/principal would approach estimation this way)

    Frame the conversation to get more informed inputs to estimates, thereby making the project delivery smoother. Mention that estimating technical tasks, especially the more complicated ones, need strong technical input. Be open to having another (more senior) engineer weigh in on the complexity and the "story points", but draw a firm line that it cannot be unilaterally decided by someone outside of the engineering function. Additionally, once the estimate is set, mention that it is counterproductive to go back on the estimate to "squeeze more juice out" when there is no change in scope / new material information.

    On a personal note, during the early stages of building my engineering team, I had to go into each project that experienced the same challenge and course correct. Over time, it's important to enable others on the team to handle the situation appropriately without my direct involvement. Getting alignment from someone senior in the engineering org is a key first step to moving in the right direction.

    13 Likes
  • Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    3 months ago

    This type of failure mode usually occurs when someone in charge of the project is solely responsible for "project management" tasks (basically cracking the whip and coordination) and usually detached from the (engineering) domain itself.

    💯💯💯

    In general, if there's a major stakeholder (i.e. they hold decision-making power) on the engineering team whose title is "Scrum Master" or "Agile Coach" but they are completely non-technical, it's not going to be great.

    11 Likes