Timeline for QA gets all the work at the end of the sprint
Current License: CC BY-SA 4.0
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 22, 2020 at 23:58 | answer | added | anichols | timeline score: 1 | |
| Oct 19, 2020 at 18:45 | vote | accept | MarkThomas52 | ||
| S Oct 14, 2020 at 4:51 | history | suggested | Cave Johnson | CC BY-SA 4.0 |
changed to better wording IMHO; remove capitalization from title
|
| Oct 14, 2020 at 2:45 | review | Suggested edits | |||
| S Oct 14, 2020 at 4:51 | |||||
| Oct 13, 2020 at 22:01 | answer | added | Robbie Goodwin | timeline score: 0 | |
| Oct 13, 2020 at 11:20 | comment | added | spikey_richie | @dzieciou A PBI is a work item type on the CMMI template, think Feature and/or User Story in an Agile template. | |
| S Oct 13, 2020 at 2:19 | history | suggested | costrom | CC BY-SA 4.0 |
Added PBI description to question; from comments
|
| Oct 12, 2020 at 18:00 | history | tweeted | twitter.com/StackSQA/status/1315713871169150977 | ||
| Oct 12, 2020 at 16:19 | review | Suggested edits | |||
| S Oct 13, 2020 at 2:19 | |||||
| Oct 12, 2020 at 12:01 | comment | added | Aaron F | @davidbak "stories in subsequent sprints typically build on stories completed in earlier sprints" - in our case the new features always build on or replace existing features. We don't do new work on features which haven't yet been tested and rolled into a release. Maybe this is a luxury other teams don't have? (We're working on a live product and are doing incremental iterative updates... generally speaking we're adding support for new technologies and dropping support for obsolete ones) What works for us might not work for everyone else. | |
| Oct 12, 2020 at 11:59 | answer | added | pjc50 | timeline score: 5 | |
| Oct 12, 2020 at 11:53 | comment | added | Aaron F | @davidbak The US won't be accepted and closed until the QA's done. Sometimes, depending on QA workload and priorities, a US will be put on hold for a sprint or two. If the feature is urgent, and the PO wants it, then it can go into the next release with minor bugs. I think the product makes a big difference, though: where I am, it's a global product with millions of concurrent users, so we take things very slowly in order to not break stuff; and, generally, developers are working on features that won't go into production for another 8 to 12 months. It's a large team and we do long sprints. | |
| Oct 12, 2020 at 11:41 | comment | added | Mr47 | @dzieciou Product Backlog Item; basically an item on the 'todo list'. | |
| Oct 12, 2020 at 10:59 | answer | added | Graham | timeline score: -1 | |
| Oct 12, 2020 at 8:30 | answer | added | o.m. | timeline score: 5 | |
| Oct 12, 2020 at 5:21 | history | edited | JAINAM |
edited tags
|
|
| Oct 12, 2020 at 5:01 | answer | added | JAINAM | timeline score: 8 | |
| Oct 12, 2020 at 2:32 | answer | added | Richard Hunter | timeline score: 6 | |
| Oct 11, 2020 at 22:02 | comment | added | davidbak | @AaronF - How does this actually work? Can a story be accepted by the product owner when it has been "developed" but won't be tested for 2-3 sprints? What's the acceptance criteria? When some story fails QA 2 or 3 sprints later - and can't go into production - how is that addressed by the dev team? And then too, stories in subsequent sprints typically build on stories completed in earlier sprints - how does that work if the stuff from earlier sprints can't be relied on or is subject to change due to not working correctly? | |
| Oct 11, 2020 at 21:58 | comment | added | davidbak | I've seen this before. It can be very demoralizing to the QA team, and frustrating for the product owners. Where I saw this - where there were 2 week sprints !! which contributed to the end-of-sprint dev rush - it was not solved but I always thought it could have been by staggering the dev and QA sprints - if there was some kind of enforcement mechanism where stuff that needed additional work to pass QA was addressed immediately by the devs even though it would impact their own (current) sprint. But maybe that doesn't work in practice either. | |
| Oct 11, 2020 at 16:16 | comment | added | Aaron F | Then the QA work should not be done in the same sprint, and the planning should take this into account. Where I work, QA team are sometimes testing Dev team work from two or three sprints before the current one. What are your QA people doing for the rest of the sprint, before the developers are finished? | |
| Oct 11, 2020 at 14:28 | comment | added | dzieciou | PBI? What is that? | |
| Oct 11, 2020 at 14:16 | answer | added | eckes | timeline score: 1 | |
| Oct 11, 2020 at 12:56 | history | became hot network question | |||
| Oct 11, 2020 at 12:30 | answer | added | Thomas Owens♦ | timeline score: 5 | |
| Oct 11, 2020 at 10:14 | answer | added | Michael Durrant | timeline score: 28 | |
| Oct 11, 2020 at 9:52 | answer | added | pavelsaman | timeline score: 5 | |
| Oct 11, 2020 at 7:59 | comment | added | João Farias | What are the reasons for your team to use sprints, rather than focus on continuous delivery, aimed at optimizing cycle time? | |
| Oct 11, 2020 at 4:57 | review | First posts | |||
| Oct 11, 2020 at 9:08 | |||||
| Oct 11, 2020 at 4:55 | history | asked | MarkThomas52 | CC BY-SA 4.0 |