To not be too broad to begin with, the direct question would be:
Is it expected that a developer should continuously remind project manages of a feature not implemented because he lacks resources to implement it?
The rules are as follows: We have a board with tasks in columns. A developer picks a task in "OPEN" and starts working on it. As he does that, he moves the task to "IN PROGRESS". When he is finished the task goes to "DEVELOPMENT DONE" (later into testing). But if something goes wrong the task should be moved into "FEEDBACK" where something needs to be resolved. Maybe design is missing or some description is unclear...
Pretty simple if you ask me.
In my opinion as developer when a task is not completable and its ticket is in "FEEDBACK", it is a responsibility of a project manager to keep track of a feature and take effort to find a person who can resolve the problem on it.
But what happened in our team: A ticket was sent to "FEEDBACK" as the API that was needed was not implemented. The ticket sat there for a few months (yes, close to half a year actually) and then at some point one of the project managers simply closed the ticket because another project manager reported that he forwarded the issue to another team. Another month passes by and suddenly this not-completed-feature comes up. Now one of the project managers is furious and claims that it is our responsibility as developers to keep track of such things and that he would expect we have some sort of list of things-that-are-not-done.
Is this true? Should we somehow keep track of some extra things next to the board we already have? I would expect that a single board should suffice for such things and the development team did all in their hands to prevent such a mess. If not, do you have any recommendation on how to avoid such problems or how to better track such potential issues?
To give a full story on how/what happened:
We are making a mobile application. A few months ago we received a request that on a specific screen (rarely seen by a user) an error may be received from the API (because of some rare situation). Now this specific error will also report a sub-error code. So if this error occurs, a sub-error
A or sub-error
B will be added. And depending on this sub-error the app needs to show either
screenB. But the API did not provide
B and the task completed could not be validated or tested.
So the ticket was put into "FEEDBACK" explaining that the API is simply not ready for it. But then some discussion started on the ticket about seeing the screen anyway just to check the design. So the developer added a logic to randomly show
screenB and reported this in the ticket which was still in "FEEDBACK".
Months passed and at some point one of the PMs tried to handle this. So he (I assume) reported this to the team responsible for API and commented on the ticket, something like "They told us this is a bug on their side. Mention: theOtherPM, can we close this ticket now?". And "theOtherPM" then closed the ticket. Another month later all hell breaks loose over this and I am confused why is this the fault of us developers.
Note: Another thing to mention is that the other team, which is responsible for the API (among other things), is not part of our network and not even part of our company. We, as the development team, have no direct communication with them. So there was no other way to solve this but through our management.