Now what if the bug that goes into the product backlog requires more investigation than usual (all bugs require investigation, but in some cases I suppose devs already have an idea of how to fix it, in some, totally no idea hence more investigation is needed): Tag it as a spike (not a term in the Scrum Guide, FYI). And if it makes it way into the Sprint Planning, then size the bug. It’ll be groomed as you would with other user stories to give it enough details for the team to work with. If it’s a bug unrelated to user stories that we’re testing this sprint (say, from an older feature) OR it’s too big a bug or complex (again implicitly sized) to be fixed within the sprint: It goes to the product backlog.If it’s a bug found during testing of a user story we’re working on in the sprint AND it’s small enough (implicitly sized) to be fixed within the same sprint: It goes into the sprint backlog.I plan to write about this in 2-parts: (1) how I might go about with it - no explanations, but based on past experiences as a member of Agile Scrum teams and what I’ve read on the topic, and (2) links and quotes galore. I found a question posted in one of the social channels at work: How should one give out story points to bugs/defects that one does not yet know how to fix yet and requires investigation? The original question asks how but I think even before we go there it would be nice to know whether we need to in the first place.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |