Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
theKarlisK777925dDid they assign the tasks knowing that you don't have the necessary experience and expected you to finish it without any learning or trial-and-error period?
netikras2659225d@theKarlisK makes a great point. TL's job is to assign tasks respectively to the skillset team members have. If the underqualified person was chosen deliberately, it's tl's job to motivate and find help and resources for that person.
Unless you were sitting duck and never told anyone you don't have what it takes, it's not really your fault.
But if you were silent... It's all on you. Learn from this lesson. Speak up next time. SPEAK!
This should never be a surprise at sprint end.
If you're struggling, speak up in standups. More to the point though, your TL should be asking for progress during standups and taking things on board. And story point estimation should mean that everyone understands the relative size of the task too.
The only way this is your fault is if you've constantly said you're making progress, but you're actually not. Beyond that,it's either the fault of your TL, or the process you're all following.
PepeTheFrog29925dIf you were not the one to choose the estimate and if there was not a ramp-up/spike task, take it as a failure to do proper work management from your superior.
I mean if you are familiar with what the task entails at all, the estimate should go way up.
Berkmann1881525dIf you had blockers and mentioned them in your standups, your superior should have found a way to (or get someone to) help you.
If you didn't speak up about that then it's on you.
I don't take scolding. Its unprofessional. My response to it, especially if due to someone else's mishandling of schedule, requirements or customers is to ask if they would immediately like my resignation.
Then I watch them backpedal and start trying to cover their ass.
craig939393256925dHere's a secret that shouldn't be a secret.
Finishing all your work in the sprint is not a requirement of a sprint. That's waterfall thinking. A sprint is a bad name, it's simply an increment to decide when you close the feedback loop, and to generate data for managers to make *estimates*.
There is no such thing as *failing* to finish a sprint. There is finding out things could be better managed, adjusting timelines based on new knowledge over time, and using the findings to produce a better team dynamic. None of this is failure.
craig939393256925d@craig939393 in fact enforcing the idea of failing a sprint can be disastrous for a team. The point of agile thinking is deliver things that are of a high enough technical quality, and are definitely what the customer wants. You deliver the right thing. Speed comes from that as a given.
Rushing to *complete* a sprint breeds shit quality and hacks. This is the exact opposite of what you want to do, if you want to go fast over a sustainable time...
I did have this feeling when I first started at my very first job. I was never scolded, but I felt very lost. Lots of nights working things out at home and making 40 hr work weeks into 80 hr work weeks without team knowing just so I could finish my work. (I took the other 40 unpaid obviously)
But yeah until you get your skillset higher it sucks.