Timeline for Should user stories be delivered orally?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14, 2022 at 18:05 | vote | accept | xoa991x | ||
| Feb 6, 2022 at 17:08 | history | edited | Barnaby Golden | CC BY-SA 4.0 |
deleted 1 character in body
|
| Feb 5, 2022 at 22:17 | comment | added | Barnaby Golden | Writing the details into a tool like JIRA is often a good idea. It may help with knowledge transfer across the team and it can help if you have to return to something in the future (say if a bug is found in that feature). Some techniques like Behaviour Driven Development (BDD) make this even more formal. I encourage you to experiment. Try different approaches until you find what works well for you and your team. | |
| Feb 5, 2022 at 22:16 | comment | added | Barnaby Golden | Doing the right amount of refinement requires practice. If you find you get to sprint planning and unexpected things pop up a lot then chances are you need to do more refinement. If you discover blockers when you start work on items then do more 'spikes' - where you spend a timeboxed amount of time investigating things before estimating on them. | |
| Feb 5, 2022 at 18:46 | comment | added | xoa991x | 2) When story details are elicited, should they be written into the story (e.g. on JIRA)? And do they remain there, as reference? Or are stories effectively obsolete once work is completed (e.g. the code/produced work is considered the documentation). | |
| Feb 5, 2022 at 18:43 | comment | added | xoa991x | 1) At which point are written details elicited? During refinement, or during the sprint? Is a one-liner still sufficient at sprint planning? I feel like many blockers are discovered immediately after beginning to work on a story. | |
| Feb 5, 2022 at 16:53 | history | answered | Barnaby Golden | CC BY-SA 4.0 |