It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787

question asked: Oct 26 '10, 5:43 p.m.
question was seen: 6,489 times
last updated: Oct 26 '10, 5:43 p.m.

Related questions

FAQ - How this Forum works

Workflow for Defect and Story work items in SCRUM template

1
Ken Murphy (103●32●35) | asked Oct 26 '10, 5:43 p.m.
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

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Nov 19 '10, 1:18 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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

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?
0
permanent link
Nils Kronqvist (41●6●2) | answered Nov 19 '10, 4:44 a.m.
JAZZ DEVELOPER
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
0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Nov 20 '10, 12:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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:
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

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.