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

Management fucked up big time i'd say. If the client defines the sprints, why don't they hire you devs directly? Some stories end like this. It will be very very very hard to convince them, that they not only need you coding but your expertise in prioritizing, estamate effords and more, if they are used to such a role. And the efford must come from your team lead and mgmt. If they don't have any interssest to chnage to relationship of the dev team and client, brace yourself. Most likely things will work some time like this until they won't because code becomes unmaintainable or all developers quit or what not. Then client an mgmt will fight who is responsible. Make sure to be somewhere else at this point.

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.