38

How do I estimate my sprint tasks better?

Profile picture
Anonymous User at Taro Community2 years ago

We have a sprint planning session every two weeks where epic owners create tickets and they are presented to people. Whoever is interested in whatever tickets, they assign it to themselves.

Everyone has 10 story points worth of tasks where 1 story point is one day’s work. When these tickets are created, the creator assigns an estimated story point value based on their judgement of the complexity of the ticket.

But sometimes, the task can be more complex than estimated and it might spill over.

I tend to take 10 points worth of tasks but definitely 1/2 points get spilled over to the next sprint because of unplanned delays while finishing them and my own inefficiency/ procrastination.

I have been given the feedback that I tend to overcommit and it would be better if I brought it up earlier in daily stand ups in case some tasks are taking more time than usual. This will enable others to pick up some other task on my board in case they are done with theirs.

I do see my inability to complete the 10 points as a personal failure even if no one explicitly points it out or cares about it. Most of my team mates tend to get them done though. I am 6 months in the team and the rest have been there for 2-3 years at least. I want to get better at planning and completing my sprint tasks. How do I approach this problem?

970
4

Discussion

(4 comments)
  • 32
    Profile picture
    Senior Staff Engineer, ex-Meta, ex-Amazon
    2 years ago

    6 months vs 2-3 years is a significant time difference, so it is not a surprise that your team mates are much better at estimations (for that particular team scope, not in general, necessarily). It is also possible that they are choosing their 10 story points more strategically with an appropriate mix of easy and risky tasks. So don't be too hard on yourself about this just yet.

    Practically, though, here are a couple approaches I can think of for you to improve -

    1. Deliberately calibrate yourself during the next few sprints; ie, next sprint, try to pick the simplest, seemingly no brainer set of tasks, and figure out how you do on them. After that, you can take on more and stretch yourself.
    2. Lean on one of your teammates that you trust to help you. Perhaps you can either do a post mortem with them on a sprint where you were esp. off with your estimates, or better yet, review your estimates upfront with them before the sprint starts.
    3. Lastly, do be proactive about signaling increased complexity/scope in your stand ups as soon as you realize it. That part is ultimately what matters; initial estimates will never, ever be consistently accurate, but "escalating early and often" when things are not going as was initially expected, and then taking action, is what makes for successful outcomes.
  • 18
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    2 years ago

    I do see my inability to complete the 10 points as a personal failure even if no one explicitly points it out or cares about it.

    Don't!

    It seems like you have great, understanding teammates. They have given you the very valuable feedback that you're biting off more than you can chew and aren't being mean about it.

    There's already enough struggle being a software engineer, especially one that's relatively new to their team. There's no need to invent more problems for yourself. 😄

    On top of the already incredible advice everyone has shared, here's some additional resources that may be helpful:

  • 16
    Profile picture
    Junior Software Engineer at Series B Startup
    2 years ago

    A ticket a day sounds kind of stressful, I hope they are not all completely unrelated and touching various domains (but maybe this is normal and Idk how most dev teams work)! I struggled with this as well but to piggy-back off of previous great comments, perhaps a way to tackle this is planning ahead the design as much as possible.

    My team has been using a 'Technical Design Document' per ticket, where we define in our own words the business needs and more importantly, formulate exactly what needs to be done; which areas of the code, which methods to modify or add, where it fits into the flow, how it affects existing logic, etc, how this will be tested. This has been monumental in getting tickets completed by or before the Sprint (story-pointing and estimating gets closer to accurate and consistent as an instinct for this naturally develops). Formerly, a lot of us just had tickets spilling over every Sprint and it felt like almost nothing was getting done.

    When I first started writing my design docs, I felt like I was moving slower and that it was actually impeding my progress. However, what it was actually doing was forcing me to face all of my 'battles' earlier on rather than half-commit through the entire Sprint. (I have also realized that my procrastination is sometimes just out of fear of embarrassment/imposter syndrome! A lot of the scary bits for me has been reaching out to the right domain experts for clarity

    )

    I can't remember which Masterclass/vid it was but recall Rahul quoting the SEAL motto, "slow is smooth, smooth is fast", and I think about it often.

  • 10
    Profile picture
    Software Engineer
    2 years ago

    Good question, I believe every developer have been struggled with that especially in the beginning of their career or starting in a new team.

    One thing that made me wonder:

    Epic owners create tickets and they are presented to people. Whoever is interested in whatever tickets, they assign it to themselves...When these tickets are created, the creator assigns an estimated story point value based on their judgement of the complexity of the ticket.

    Sounds like the creator estimates the task not you. Is that the case? If yes (I hope not), for me, this is totally wrong. Often it's hard to make estimations yourself when you know yourself very well and know what you are capable of. Now imagine if you have to do it for someone else. This guy should know you really well, better than you. So, someone is setting the pace for the entire team which I can't agree cause you aren't (most likely) at the same level. I can write a lot how wrong for me is this, so I hope this is not the case.

    One idea, which adds to one of @Rama's suggestions - since the backlog typically is prepared in advance, check if you can prepare in advance about understanding of some of the tasks. See how good are you in each one of them and act fast later. If your have good relationship with the other team mates, ask them if you can pick those tasks before the planning :)