I'm having a weird time with my current project.There are many companies involved and we are several teams coordinating with each other. My team was initially very large, for various reasons we were divided into smaller groups and I must say that the transition has been catastrophic.

We are doing SCRUM…sort of. The customer assigns the tasks to be completed at the end of the sprint, the story points are given without full understanding of the implementation and the deadlines are tights. I always find myself rushing to the release day with code that isn't production-ready but since the customer requests it and there's no objection among my superiors (please note, i tell them the deadline is tight) I gotta rush to deliver.

The customer doesn't know what he wants, but if he does know the deadline is unreasonable, or if he has just an idea of what he wants he still demands it... somehow without specifying what kind of implementations is expecting.

The current senior project developer takes everything (any task) as an emergency, it's never possible to defer to the next sprint, it's quite demeaning.

And I'm here wondering if maybe I've missed something, if the project simply lacks method and coordination, if I have more responsibility than I think, if my project leadership is too absent but I know one thing, at the moment I'm in anxiety about the current sprint due date because there is a task that will take longer than expected.

Any advice?

Are you team lead or something?

@ScriptCoded I'm a simple developer

@ScriptCoded "my project leadership" I meant the people above me, up the ladder

One thing that is big in scrum, yet often completely left out (sadly): Transparency.

E.g. a daily scrum meeting is *not* an status update, it is also the time to e.g. say: "Danger, sprint goal will not be achieved"

That transparency should be communicated up the chain.

While some managers are afraid, me I don't give a fuck.

"Stakeholders / Customer / Client XY, due to "Blabla" the current sprint goals will not be achieved.

Please read carefully the next section."

The next section then the gory facts.

Don't bother sugar coating it or trying to make it "sound right".

If e.g. stakeholders prioritized too many tickets as high, give them the full monty:

"The sprint had 55 tickets in priority, we could only solve 7. The number of priority tickets is thus far too high."

Plus e.g. (depending on situation):

Of the 7 tickets, 3 tickets were underestimated regarding time. The other 4 tickets were estimated correctly, but there were issues regarding proper communication and task description".

Write a short and precise list of possible improvements:

"Tickets should be prioritized more clearly. Task descriptions need to be more precise, as an example: <Ticket ID> missed <XY>, team <Z> needs to communicate more with Team <Y>. Overall, the number of tickets in sprint need to be reduced, they exceeded by far what was achievable in the sprint time."

All just fictional examples. But it's really important to point out flaws. Not personally, not with name calling, just simple facts. Precise surgery, not mindless butchering so to speak.