Timeline for Where to (initially) create a task/bug with the Spotify model
Current License: CC BY-SA 4.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 4, 2020 at 10:18 | comment | added | Thomas Owens♦ | @JakobBuskSørensen You can fix the project approach by setting up one project with the right issue types, fields, and workflows and bulk moving from the others into it, even setting a new "team" field and others first. As far as assigning them, regardless of where the bug report comes from, you need a triage process to determine if it's really a bug, what the risk and impact is, if there are workarounds, what the priority is, who the right team to investigate and fix is, and so on. Whether that's at a PO meeting or something else is up for you to decide. | |
| Aug 4, 2020 at 5:56 | comment | added | Jakob Busk Sørensen | Interesting take on things. We are currently using the 1 squad : 1 Jira project approach, which may have been a mistake, but you gotta work with what you got :-). By "Black box testing" i just mean anything that isn't captured by automated testing, it could also be user reported bugs. How would you assign them, to the relevant squad? At the next-coming PO-meeting? | |
| Aug 3, 2020 at 21:46 | history | answered | Thomas Owens♦ | CC BY-SA 4.0 |