[jsdalton]

This is where feature flags come in. When you use feature flags to support development you ship code straight to production — but your work is hidden behind that glad while development is under way. So in practice you merge your PRs immediately to master (and deploy).

Essentially you’re decoupling release from development here. This supports any number of QA practices. (We don’t have dedicated QA at the moment and instead have a biweekly “mob QA” session where we do a group deep dive into our current work.) We will capture most small fixes and improvements as sub tasks on the appropriate story (or file a bug ticket if the story was already done and we discovered a new issue.)

As a result of the above we don’t use long lived feature branches which become painful and slow, process wise. We just merge immediately after review. (Unmentioned but this is of course supported by automated testing and continuous deployment.)

[tunesmith]

Thanks, this is super helpful. For us, we are pretty heavy with manual QA, and for work that can't be wrapped in feature flags, we'd still have to test a fair amount before merge, but at least it wouldn't have to be for every PR.

For post-release QA, at what point do you close the story? After all the subtasks are merged/deployed? Or later, after QA is done and they turn on the feature flag?