Nella storia 1, vorrei solo indicare quali operazioni l'utente può / vuole fare sui dati già presenti sul dispositivo e aggiungere una nota esplicita che l'origine dei dati non rientra nell'ambito della storia (eventualmente con un riferimento alla storia che gestisce il recupero / aggiornamento dei dati)
Il tuo suggerimento per la storia 2 sembra ragionevole, e la storia 3 potrebbe essere qualcosa come ", ma non voglio che Joe Random User sia in grado di accedere a quelle [entità] ". Questo dovrebbe darti l'incentivo per aggiungere la funzione di autenticazione, in modo che l'utente reale possa provare di non essere Joe Random User.
@thecapsaicinkid ha scritto in un commento:
If I'm splitting my stories in a way which requires me to fake data, is this an indication I'm not splitting in a helpful way?
Non necessariamente. Se la storia che richiede i dati falsi e la storia che sostituisce i dati falsi con i dati reali sono nello stesso sprint, non è affatto un problema. Alla demo non dovrebbe nemmeno essere evidente che è stato utilizzato a metà strada i dati falsi sprint.
Se le due storie vengono programmate per gli sprint adiacenti, sarebbe al massimo un fastidio minore che il risultato del primo sprint non possa essere implementato in modo significativo per gli utenti finali. Potrebbe diventare un problema se la storia per fornire i dati reali viene spinta più indietro nel backlog, ma non è molto probabile.
A 'thin slice' which relies on fake data has value to the business;
they can see the application working. But it has practically no
benefit to the end-user. Should I try and simplify my slice even
further (maybe a simpler UI) so I can find the time to get some real
data into the system and have an app which does at least something
useful to the end user?
Dipende e dovrebbe davvero essere discusso con il rappresentante del cliente.
A volte sarebbe meglio suddividere un'epica in sezioni verticali (diverse storie, in cui ogni storia contiene sia il recupero dei dati, la manipolazione e l'interfaccia utente). E a volte devi solo accettare che è impossibile dividere un'epopea in più storie che sono tutte rilevanti per l'utente finale.
Se è così, non preoccuparti troppo. Il rappresentante del cliente molto probabilmente capirà la situazione e cercherà di dare priorità alle storie in modo tale che l'intera epica venga completata nel minor numero possibile di sprint (è nel loro interesse).