Timeline for breaking down a feature into stories and avoiding dependencies
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 10, 2019 at 16:11 | vote | accept | djt | ||
| Aug 10, 2019 at 16:10 | comment | added | djt | Tha makes sense, and yes, the other story could ship a year later (in theory) | |
| Aug 9, 2019 at 14:48 | comment | added | Bart van Ingen Schenau | @djt, can you implement one of those stories and postpone the other till next year? If so, the stories are not dependent on each other. It can be that the latter story can reuse code from the earlier story, but that should only affect the estimate. If need be, estimate both for the full work and re-estimate once one is planned even if you are in the middle of a planning session. | |
| Aug 9, 2019 at 14:10 | comment | added | djt | Thanks for your input. While that all makes sense, in practice, I find that its sometimes difficult to apply. For example: "As a new user, I want to be able to signup for the service with my phone number, because that's the most convenient method" . AND "As a new user, I want to be able to signup for the service using my email address, becuase I'm not comfortable providing my phone number". Those could be two separate stories, and we have designs for all the flows from our designer, but there's also lots of overlap between those flows and designs, so they are not truly independent. | |
| Aug 9, 2019 at 9:43 | history | answered | Tiago Peres | CC BY-SA 4.0 |