La risposta di S.Lott è buona, ma voglio solo enfatizzare:

User goes to page x and clicks on date to launch a native date picker

Non è una storia di un utente, è una decisione di design !

Una user story sarebbe:

Essendo un adolescente ossessionato dai messaggi di testo, desidero [programmare un futuro messaggio di testo] in modo che [possa infastidire i miei amici mentre dormo]

Formato: Come [ruolo utente], voglio [fare o ottenere qualcosa] in modo che [dichiarazione di beneficio]

La trama è un segnaposto per una conversazione tra il team di sviluppo e gli stakeholder. Il design è fatto dal team di sviluppo (che include le persone UX). La creazione di librerie riutilizzabili è totalmente al di fuori dell'ambito delle storie .

Senza offesa, ma mi sembra che il tuo intero processo di sviluppo "agile" sia rotto .

Have you ran into this problem and, if so, have you found a way to consolidate the discrepancies between user stories and the concept of reusable component code for the dev team?

"discrepanze" indica che potresti non riuscire a capire il ruolo delle storie degli utenti.

Sono solo requisiti. Non progettare.

Devi capire le storie e poi (da loro) fare il lavoro di progettazione.

Il punto di un metodo Agile è di bilanciare il buon design con la noiosa documentazione eccessiva dei dettagli di progettazione che (a) non hanno importanza e (b) cambieranno.

Ma continui a progettare, anche se sei Agile. Devi solo fare un minimo, un buon design. Design massimo non esagerato.

Quando leggi una storia di un utente, devi "prendere le storie degli utenti e utilizzare [tali requisiti] per migliorare la nostra [biblioteca di progettazione]". Questo è ciò che significa "capire" significa una storia utente.

Niente è sbagliato in questo. Non dovrebbe essere una lotta. Questo è quello che dovresti fare. Altrimenti, stai saltando il design essenziale del software utilizzabile. La mancata progettazione è il modo in cui maturate il debito tecnico.

Sia @ S.Lott che @Steven A. Lowe hanno risposto al tuo problema. Non prenderei in considerazione la frase che hai postato come user story. È più simile a un compito.

Ciò che aggiungerei a queste risposte è la considerazione sulla "libreria dei componenti". Non iniziare con un componente riutilizzabile quando vedi per la prima volta il pezzo di codice che pensi possa essere riutilizzato in futuro - questo è un approccio completamente negativo. Quando si sviluppa SW in modo agile si aggiunge il codice minimo (che soddisfa alcune pratiche di programmazione comuni) necessario per implementare il valore aziendale. Una volta che è stato sviluppato un nuovo requisito, puoi scoprire che hai già fatto qualcosa di simile e solo allora puoi refactoring il codice e renderlo riutilizzabile per quei noti due casi . È possibile ripetere questo processo una volta che si ottiene di nuovo un altro requisito adatto al componente. Si noti che è necessario disporre di una suite di test per convalidare che il refactoring non ha infranto il codice esistente. Non aggiungere la riutilizzabilità al componente in anticipo, che può essere uno spreco se non sarà necessaria la riusabilità o se i requisiti per la riusabilità saranno diversi da quelli previsti.

Il caso particolare è la riusabilità tra i progetti. Dovresti avvicinarti a questo con cautela. Direi che la seconda necessità per lo stesso componente non soddisfa ancora i tempi di investimento nella componente generale.