Workflow for Defect and Story work items in SCRUM template
Where can I find an explanation of the workflow (lifecycle) for Defect and Story work items in the RTC SCRUM process tempate? I would be especially interested in what all of the various actions and state transitions were intended to be used for. Many are obvious. Others are not. Is this documented somewhere?
3 answers
I'm not aware of documentation on the state diagrams.
If you have any specific questions, we might be able to answer them.
Cheers,
Geoff
If you have any specific questions, we might be able to answer them.
Cheers,
Geoff
Where can I find an explanation of the workflow (lifecycle) for Defect and Story work items in the RTC SCRUM process tempate? I would be especially interested in what all of the various actions and state transitions were intended to be used for. Many are obvious. Others are not. Is this documented somewhere?
Hi,
(Chiming in as I have a question in the context ..)
There are two Closed states, Verified and Resolved. And you can transition from Resolved to Verified, and then from Verified back to Resolved.
What is the reasoning around this, i.e. why possible to go back from Verified to Resolved?
IMO might make sense having two Closed states, where some can be marked Resolved, but not verified -- and some also being Verified. And you can then have team rules wrt what state they needs to be depending on test strategies. But why having the "back" transition?
Rgs,
/N
(Chiming in as I have a question in the context ..)
There are two Closed states, Verified and Resolved. And you can transition from Resolved to Verified, and then from Verified back to Resolved.
What is the reasoning around this, i.e. why possible to go back from Verified to Resolved?
IMO might make sense having two Closed states, where some can be marked Resolved, but not verified -- and some also being Verified. And you can then have team rules wrt what state they needs to be depending on test strategies. But why having the "back" transition?
Rgs,
/N
I'm guessing the following was intended:
Let's suppose that someone ran some tests to verify the bug was fixed,
but then you (or someone) decided that more comprehensive verification
was needed. You then transition back from "Verified" to just "Resolved"
(hopefully, with some comment about the additional testing desired).
Can anyone from the process team (or whoever it was that designed this
state model) confirm/ this interpretation?
In general, I agree that this should be documented. I've submitted work
item 140418: "Document the intended meanings of the Predefined Process
Template work item states and state transitions"
Cheers,
Geoff
On 11/19/2010 4:53 AM, nkronqvist wrote:
Let's suppose that someone ran some tests to verify the bug was fixed,
but then you (or someone) decided that more comprehensive verification
was needed. You then transition back from "Verified" to just "Resolved"
(hopefully, with some comment about the additional testing desired).
Can anyone from the process team (or whoever it was that designed this
state model) confirm/ this interpretation?
In general, I agree that this should be documented. I've submitted work
item 140418: "Document the intended meanings of the Predefined Process
Template work item states and state transitions"
Cheers,
Geoff
On 11/19/2010 4:53 AM, nkronqvist wrote:
Hi,
(Chiming in as I have a question in the context ..)
There are two Closed states, Verified and Resolved. And you can
transition from Resolved to Verified, and then from Verified back to
Resolved.
What is the reasoning around this, i.e. why possible to go back from
Verified to Resolved?
IMO might make sense having two Closed states, where some can be
marked Resolved, but not verified -- and some also being Verified.
And you can then have team rules wrt what state they needs to be
depending on test strategies. But why having the "back"
transition?
Rgs,
/N