Just my two cents, but I think you're taking a good approach with #3.<p>Reasoning:<p>In addition to the task-state problem you mention, it's nice to treat written feature requests as near-immutable. Updates to them after they're written -- especially when initiated outside the development team -- can lead to the classic complaint around "ever-shifting requirements". So that's another reason to avoid #1.<p>Subtasks (approach #2) is a bit better, but again it involves changing an object/document that may have previously been considered relatively stable.<p>Perhaps you had estimates and sprint scopes attached to the parent task -- if so, adding/modifying subtasks could invalidate (or at least confuse) those.<p>Under these considerations, #3 therefore wins as a kind of 'append-only log' of tasks.<p>If you can, and if your organizational culture supports it, you could ask QA to indicate whether they feel that the issues they raise reflect problems in the original requirements, or implementation problems.<p>That way you may be able to align product managers with precise requirements authorship, and developers with quality implementation by identifying and improving the areas where bugs are being raised.<p>Of course, QA intensity and output could vary as well, so it's not foolproof. And as with any theoretical work process, it often falls apart due to practical considerations like staffing changes, project/company direction shifts, and so forth. So you shouldn't cling to it at the detriment of the team's health and progress.<p>But the long and short of it is that #3 seems like a good approach to me :)