1) Ideally the designer and dev are together, and your Sketch library components translate directly to the front-end library on the dev side. In this manner, if you're successful, you should be able to give a dev a WIREFRAME and they reconstruct it with the proper front end components. Your Sketch components are basically reverse engineered "sort of like this" mock-ups. The designer needs to be in-team OR you have a regular culture of demoing stories to the team/designer directly.
or
2) If a designer and developer can't sync-up together regularly (too many devs per designer is often the cause, but also the designer can be away on vacay or some other perfectly legit reason, etc). you can use Zeplin.io — it's a great service. This would work for 1) too, really. It also serves to make sure a designer has their UI measured and properly put together (no 9, 10,11,9 margins allowed here).
It's really up to the designer to facilitate this on the day-to-day level—and for eng management to set the team expectations on what is considered "done". Or else you run the risk of missing the boat, because even in the best Agile environment you have to move on to other initiatives at some point, and that will cause a backlog of design debt.
It's not a one size fits all issue:
1) Ideally the designer and dev are together, and your Sketch library components translate directly to the front-end library on the dev side. In this manner, if you're successful, you should be able to give a dev a WIREFRAME and they reconstruct it with the proper front end components. Your Sketch components are basically reverse engineered "sort of like this" mock-ups. The designer needs to be in-team OR you have a regular culture of demoing stories to the team/designer directly.
or
2) If a designer and developer can't sync-up together regularly (too many devs per designer is often the cause, but also the designer can be away on vacay or some other perfectly legit reason, etc). you can use Zeplin.io — it's a great service. This would work for 1) too, really. It also serves to make sure a designer has their UI measured and properly put together (no 9, 10,11,9 margins allowed here).
It's really up to the designer to facilitate this on the day-to-day level—and for eng management to set the team expectations on what is considered "done". Or else you run the risk of missing the boat, because even in the best Agile environment you have to move on to other initiatives at some point, and that will cause a backlog of design debt.