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.

Senior Staff Engineer, ex-Meta, ex-Amazon

Rama Karve

First off, please do make sure your manager is aware that you are motivated to grow to the next level. At senior levels, this is not a given, so explicitly stating your intent is sometimes necessary to get your manager motivated as well :)\
\
Next, assuming there is some well known expectation of what the staff level looks like in your company, collaborate with your manager to identify what gaps you have (do some introspection first instead of having your manager do all that work). \
\
Document these, along with some proposals for how to address them. This should be a working doc that you and and your manager review at some regular cadence. 

> My manager is not very vocal or supportive and seems reluctant in terms of helping out a plan for myself.

None of us can comment on the specifics here, of course, but I'd debug this a little bit with them. Another thing to note is that in some companies, staff level promos are not just about individual readiness, but also whether there is actually sustained scope in the team's charter, for that level.  

> I have been working hard though.

Unfortunately for all of us who've been there, effort is not always positively correlated with outcomes, and it is ultimately the outcomes that matter. So please do make sure you are leveraging your strengths and are working toward the right outcomes. 

> I am not sure if I should move up the engg ladder or transition to management but are there any guidelines for creating a written promotion plan and manage up so to speak

I assume there is some existing reference material on Taro about the differences between IC and manager roles, and how to think about a transition, so please look for them. But the crux of the matter is that transitioning to management does not obviate the need to "manage up", so learning these skills will help you in either case. 

That's a lot of good detailed questions! I may not be able to answer all of them, but I'll make a few general points, that I hope will be helpful to you in assessing your particular situation.

1\. A mentorship is a two way street. How much time you spend on it is a negotiation between how much the mentee wants and needs, and how much you, as the mentor, is able and willing to give. As a mentor, how much time you spend will also depend upon the relationship you have with your mentee outside of the mentorship; ie. is the mentee on your team? Are they new to the company/org/team? Are y'all working on the same project? Is your success, and the success of your project dependent on this mentorship being successful? Or is this a traditional mentorship, where the mentee is outside your immediate sphere, and you are purely helping them with their specific career goals.

2\. Your role as a mentor does not have to be about giving away all the answers and explanations, but to facilitate your mentee's ability to make progress on their own (ie. the classic 'teach them to fish' principle). For example, if they are are asking you generic questions that can answered via a google search, or some internal wiki, then ask them to use those resources, before approaching you with questions. Or help them determine a reasonable amount of time (few hours, perhaps a day) that they should spend independently trying to unblock themselves, before reaching out to you/others for help, and conversely, when to absolutely get some help, whether you are available or not.

3\. In most cases, it does not matter to what pre-existing gaps someone has, whether those gaps should exist or not, whether they have previous experience, as long as the mentee is able able to learn, make progress, and fill those gaps. Some people need more support than others, so do give them some benefit of doubt. But if you are not seeing evidence of learning/improvement, then that's a concern, and a signal to evaluate if the mentorship is working or not. I acknowledge that this is an inexact science and not always easy to know for sure.

Also, since it is not clear from your question, I'd recommend spending a few moments to evaluate whether it is just you, personally, experiencing poor communication from one or more XFN partners, or if the entire XFN team is plagued by poor communication. If the latter, then that can signal misalignment across different teams/job functions, and you'll need to leverage your TL/manager to help resolve that.

If you think it is just you, then Alex covers that in his answer really well. The only thing I would add is to make sure that the person you are expecting code reviews from is actually aligned that they are in a critical path for your p0 goals and have the bandwidth and are committed to support you with reviews. Set up a 1-1 and talk to them, so that you can understand their PoV!

Working closely together for 4+ hours would hit most people's limits of productivity. 

So, honestly, it is perfectly okay to say that "you need to take a break". You could also mention that you need to get something done before the end of the day or such, even if that "something" is sitting quietly by yourself, or whatever you need to recharge.  If there is work still remaining to be done, then for bonus points, try to split some of it in a way that can be completed independently, and then suggest an appropriate later time to "regroup". 

Lastly, I get that you may feel like you need to be 'ON' when working with your team mates, but you don't necessarily need to be positive all the time, especially with folks that you work with.   