No! No! No! No! WHY??
We spend years saying "software development is not manufacturing", and now it the name of "agile" we allow all this to crept back.
Your team is not falling behind, your estimates were wrong!!
The penny game (where I work we call it the beer game) is a good learning exercise, but in software development you really don't want to be having different "stations" handing work off to each other in the first place, because that leads to delays and quality issues. Each station will develop its own little backlog and pretty soon a feature cannot make it from start to finish without spending weeks waiting in the design queue, then the dev queue, then the test queue...
Instead, you need to have a small, cross-functional team focusing on the same piece of the product at the same time, collaborating and giving rapid feedback on each other's work--that's what agile and XP and scrum are for. And you need a pull system instead of a push system, to regulate the amount of work in progress--that's what kanban boards are for.
Understanding how the data model is laid out, how much structure is needed, what fields are required/optional and what types they are etc. can also inform UI/UX design decisions.
And this is an example of two roles that are at opposite ends of the frontend/backend spectrum. For roles whose work products interface directly, there's an even stronger need to collaborate.
Specialization is good in that it allows people to focus on using their best skills, but it's bad if it fragments the product development team and inhibits communication and decisionmaking.
But when you tighten the feedback loop and shrink the batch size of the work, you make the dependencies smaller and more granular, so the queue gets smaller and fluctuates less, and you get better flow of work through the process.
Here's a simple visual that illustrates why this is the case:
https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOf...
This article isn't about meeting (or failing to meet) deadlines, it's about work-in-progress building up.
To my mind the costs of context switching are pretty well established at this point and the value of limiting work in progress is clear enough from experience, but that's just my experience and maybe you disagree.
That's not what I'm advocating. All I meant to say is that when you have a lot of work in progress you get less done, whether or not you have deadlines.
Lean, and Japanese manufacturing the worker has a lot power(They can stop the line) and have final say in quality.
This is modeling how people organize in hard Math, and getting real results to improve a situation. It is not equating software to manufacturing.
Or your business model doesn't support your technical goals. That is, your business model doesn't work.
"I don't know yet. I need three days and I'll give you a better answer." is often a great estimate.