4 ms·
Testing should occur within the same sprint as dev where possible - if you're throwing all work over a fence to a distinct QA team, you're doing it wrong. If t
by alistairSH 4y ago
Testing should occur within the same sprint as dev where possible - if you're throwing all work over a fence to a distinct QA team, you're doing it wrong.
If testing in "real time" is not possible for some reason, the following sprint should have testing support baked in as an explicit task.
And, IME, sprints work well for mature products where there's a steady flow of defects and enhancements that are relatively easily articulated. Sprints work less well for greenfield development with new tech - you just end up with long strings of spikes/analysis/PoC work (it can still work, but you tend not to have concrete deliverables each sprint).
- spaetzleesser 4y ago“ if you're throwing all work over a fence to a distinct QA team, you're doing it wrong.” That’s how it works in an industry where product bugs can kill people. The devs do their own testing but there are large testing teams that take a deep look at at everything the system does.
- alistairSH 4y agoFair enough, that's why my second sentence is there. The scrum master/manager should be building in QA support. If they aren't, they'r failing at their job. A individual developer should never be put in the position of killing a sprint in order to support a QA team for work the dev team did last week.