Timeline for How do we prevent debates over whether changes to user stories are new work or bugs?
Current License: CC BY-SA 3.0
4 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 15, 2016 at 16:30 | comment | added | RubberDuck | I think the biggest take away here is that the PO signs off on user stories after they're implemented. Discrepancies between what the PO expected/wanted and what you delivered get captured as bugs and prioritized appropriately. Remember, we're not delivering functionality. We're delivering an experiment that may or may not stay in the code base. | |
May 12, 2016 at 22:33 | comment | added | Barnaby Golden | The Product Owner is continually reviewing the stories in the product backlog. If they had a discussion that had implications for these stories they would update them where necessary. Also, as a story gets close to being worked on the Product Owner may well make some notes about the details of the requirement. It's all about adding the details at the last possible moment to reduce the impact of change and to lower the risk of misunderstandings. | |
May 12, 2016 at 22:29 | comment | added | dreza | but some decisions made can effect stories to come later on. How would these be captured outside of "conversations" | |
May 12, 2016 at 22:20 | history | answered | Barnaby Golden | CC BY-SA 3.0 |