As background: We have our status values defined as open/in progress/blocked/complete.
Since human beings are not always primarily focused on keeping data fully up-to-date, we often see the following situations: * The first person starts work on a new story (picks up a task & logs hours), but fails to change task status to "in progress". * Task status is changed to "in progress", but the story status is not properly updated and remains at "open". * People close tasks while their status is something other than "complete". * Story status is set to "complete" while some tasks remain in a status other than "complete" and/or have to do > 0.
Common questions I get are: Why doesn't the system do this automatically? Or: Why does the system allow this to happen?
I understand that VersionOne doesn't "understand" what the statuses "mean" because it's a list of values that's custom and specific to the implementation. VersionOne only knows if something is open or closed.
Then again, with a little parameterization, one could address a number of these issues: If there were (optional) parameters like "in progress status: A" and "final status: B" or something, the system could automatically update task and story status to "A" as soon as hours are burned. Then, when tasks or stories are closed, the status could default to "B" (with the user being able to overwrite if necessary).
I understand that this would lead to a more interpretative view of the status fields. Right now they are seen as independent from open/closed and VersionOne couldn't care less about the status values. But by tying them together at least loosely, it would greatly help users with keeping data accurate.
What do you guys think? Do you have similar challenges? How do you define your list of statuses and how do you get teams to keep them current?
I would love to remove the status column altogether and just use the
to do column as an indication of status (different than estimate = in
progress, zero = done). I could have done this in my last group since
we had a physical taskboard in our team room and would have only used
V1 to track the tasks and burndown.
In my current group I can't do this and these questions come up a lot
because we are maturing into agile. People like the status more than
the to do as a measurement of progress. We do our best to balance the
issues and I try to keep focusing people on distance from DONE. It
might be nice if the system could be configured to have status updates
based on other event triggers, but I fear it only keeps people from
understanding agile practices better as they rely on GANTT-like
statusing.
As for your 4 points, I completely ignore the last issue. If the
story or task is closed, then that overrides whatever the status may
or may not say (it helps that the to do is cleared in the process).
On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> As background: We have our status values defined as open/in progress/blocked/complete.
> Since human beings are not always primarily focused on keeping data fully up-to-date, we often see the following situations:
> * The first person starts work on a new story (picks up a task & logs hours), but fails to change task status to "in progress".
> * Task status is changed to "in progress", but the story status is not properly updated and remains at "open".
> * People close tasks while their status is something other than "complete".
> * Story status is set to "complete" while some tasks remain in a status other than "complete" and/or have to do > 0.
> Common questions I get are: Why doesn't the system do this automatically? Or: Why does the system allow this to happen?
> I understand that VersionOne doesn't "understand" what the statuses "mean" because it's a list of values that's custom and specific to the implementation. VersionOne only knows if something is open or closed.
> Then again, with a little parameterization, one could address a number of these issues: If there were (optional) parameters like "in progress status: A" and "final status: B" or something, the system could automatically update task and story status to "A" as soon as hours are burned. Then, when tasks or stories are closed, the status could default to "B" (with the user being able to overwrite if necessary).
> I understand that this would lead to a more interpretative view of the status fields. Right now they are seen as independent from open/closed and VersionOne couldn't care less about the status values. But by tying them together at least loosely, it would greatly help users with keeping data accurate.
> What do you guys think? Do you have similar challenges? How do you define your list of statuses and how do you get teams to keep them current?
Is there any way to assign the same custom field to both a story and a defect? Otherwise I have to add them in both places and end up with 2 columns for the same field when stories and defects are displayed together:
You can do this via the Custom Columns tab. Select the Assign Field
option and choose the additional column you created. Once you assign
it you can then delete the column you just assigned.
> Is there any way to assign the same custom field to both a story and a
> defect? Otherwise I have to add them in both places and end up with 2
> columns for the same field when stories and defects are displayed
> together:
> I would love to remove the status column altogether and just use the
> to do column as an indication of status (different than estimate = in
> progress, zero = done). I could have done this in my last group since
> we had a physical taskboard in our team room and would have only used
> V1 to track the tasks and burndown.
> In my current group I can't do this and these questions come up a lot
> because we are maturing into agile. People like the status more than
> the to do as a measurement of progress. We do our best to balance the
> issues and I try to keep focusing people on distance from DONE. It
> might be nice if the system could be configured to have status updates
> based on other event triggers, but I fear it only keeps people from
> understanding agile practices better as they rely on GANTT-like
> statusing.
> As for your 4 points, I completely ignore the last issue. If the
> story or task is closed, then that overrides whatever the status may
> or may not say (it helps that the to do is cleared in the process).
> On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > As background: We have our status values defined as open/in progress/blocked/complete.
> > Since human beings are not always primarily focused on keeping data fully up-to-date, we often see the following situations:
> > * The first person starts work on a new story (picks up a task & logs hours), but fails to change task status to "in progress".
> > * Task status is changed to "in progress", but the story status is not properly updated and remains at "open".
> > * People close tasks while their status is something other than "complete".
> > * Story status is set to "complete" while some tasks remain in a status other than "complete" and/or have to do > 0.
> > Common questions I get are: Why doesn't the system do this automatically? Or: Why does the system allow this to happen?
> > I understand that VersionOne doesn't "understand" what the statuses "mean" because it's a list of values that's custom and specific to the implementation. VersionOne only knows if something is open or closed.
> > Then again, with a little parameterization, one could address a number of these issues: If there were (optional) parameters like "in progress status: A" and "final status: B" or something, the system could automatically update task and story status to "A" as soon as hours are burned. Then, when tasks or stories are closed, the status could default to "B" (with the user being able to overwrite if necessary).
> > I understand that this would lead to a more interpretative view of the status fields. Right now they are seen as independent from open/closed and VersionOne couldn't care less about the status values. But by tying them together at least loosely, it would greatly help users with keeping data accurate.
> > What do you guys think? Do you have similar challenges? How do you define your list of statuses and how do you get teams to keep them current?
My $.02: I kind of like having a separate status field. It lets you mark things as "In Progress" vs. "Not Started", and separates the issue of how much work is left.
It wouldn't give me great heartburn to lose that, but it seems less intuitive to me.
I think it does make sense to give more tie-in between the involved fields, to avoid things getting out of synch.
-----Original Message-----
From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
Sent: Tuesday, November 11, 2008 1:32 PM
To: VersionOne-users
Subject: Re: automatic update of task/story status
I'd like to hear from others on this request...would this help your
teams?
-Luanne
On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> I would love to remove the status column altogether and just use the
> to do column as an indication of status (different than estimate = in
> progress, zero = done). I could have done this in my last group since
> we had a physical taskboard in our team room and would have only used
> V1 to track the tasks and burndown.
> In my current group I can't do this and these questions come up a lot
> because we are maturing into agile. People like the status more than
> the to do as a measurement of progress. We do our best to balance the
> issues and I try to keep focusing people on distance from DONE. It
> might be nice if the system could be configured to have status updates
> based on other event triggers, but I fear it only keeps people from
> understanding agile practices better as they rely on GANTT-like
> statusing.
> As for your 4 points, I completely ignore the last issue. If the
> story or task is closed, then that overrides whatever the status may
> or may not say (it helps that the to do is cleared in the process).
> On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > As background: We have our status values defined as open/in progress/blocked/complete.
> > Since human beings are not always primarily focused on keeping data fully up-to-date, we often see the following situations:
> > * The first person starts work on a new story (picks up a task & logs hours), but fails to change task status to "in progress".
> > * Task status is changed to "in progress", but the story status is not properly updated and remains at "open".
> > * People close tasks while their status is something other than "complete".
> > * Story status is set to "complete" while some tasks remain in a status other than "complete" and/or have to do > 0.
> > Common questions I get are: Why doesn't the system do this automatically? Or: Why does the system allow this to happen?
> > I understand that VersionOne doesn't "understand" what the statuses "mean" because it's a list of values that's custom and specific to the implementation. VersionOne only knows if something is open or closed.
> > Then again, with a little parameterization, one could address a number of these issues: If there were (optional) parameters like "in progress status: A" and "final status: B" or something, the system could automatically update task and story status to "A" as soon as hours are burned. Then, when tasks or stories are closed, the status could default to "B" (with the user being able to overwrite if necessary).
> > I understand that this would lead to a more interpretative view of the status fields. Right now they are seen as independent from open/closed and VersionOne couldn't care less about the status values. But by tying them together at least loosely, it would greatly help users with keeping data accurate.
> > What do you guys think? Do you have similar challenges? How do you define your list of statuses and how do you get teams to keep them current?
It would cause trouble for our team, for the same reason given by Jeff Pek.
I would add more emphasis, because our list of Status conditions has several
other 'steps' which are very useful to us.
My $0.02,
Lea
_________________________________
Lea Rush
Software and Documentation Specialist
Astoria-Pacific International
PO Box 830 Clackamas OR 97015
PH: 800-657-3010
FAX: 503-655-7367
> -----Original Message-----
> From: versionone-users@googlegroups.com [mailto:versionone-
> users@googlegroups.com] On Behalf Of Luanne
> Sent: Tuesday, November 11, 2008 10:32 AM
> To: VersionOne-users
> Subject: Re: automatic update of task/story status
> I'd like to hear from others on this request...would this help your
> teams?
> -Luanne
> On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > I would love to remove the status column altogether and just use the
> > to do column as an indication of status (different than estimate = in
> > progress, zero = done). I could have done this in my last group since
> > we had a physical taskboard in our team room and would have only used
> > V1 to track the tasks and burndown.
> > In my current group I can't do this and these questions come up a lot
> > because we are maturing into agile. People like the status more than
> > the to do as a measurement of progress. We do our best to balance the
> > issues and I try to keep focusing people on distance from DONE. It
> > might be nice if the system could be configured to have status updates
> > based on other event triggers, but I fear it only keeps people from
> > understanding agile practices better as they rely on GANTT-like
> > statusing.
> > As for your 4 points, I completely ignore the last issue. If the
> > story or task is closed, then that overrides whatever the status may
> > or may not say (it helps that the to do is cleared in the process).
> > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > As background: We have our status values defined as open/in
> progress/blocked/complete.
> > > Since human beings are not always primarily focused on keeping data
fully up-
> to-date, we often see the following situations:
> > > * The first person starts work on a new story (picks up a task &
logs hours),
> but fails to change task status to "in progress".
> > > * Task status is changed to "in progress", but the story status
is not properly
> updated and remains at "open".
> > > * People close tasks while their status is something other than
"complete".
> > > * Story status is set to "complete" while some tasks remain in a
status other
> than "complete" and/or have to do > 0.
> > > Common questions I get are: Why doesn't the system do this
automatically? Or:
> Why does the system allow this to happen?
> > > I understand that VersionOne doesn't "understand" what the statuses
"mean"
> because it's a list of values that's custom and specific to the
implementation.
> VersionOne only knows if something is open or closed.
> > > Then again, with a little parameterization, one could address a number
of these
> issues: If there were (optional) parameters like "in progress status: A"
and "final
> status: B" or something, the system could automatically update task and
story
> status to "A" as soon as hours are burned. Then, when tasks or stories are
closed,
> the status could default to "B" (with the user being able to overwrite if
necessary).
> > > I understand that this would lead to a more interpretative view of the
status
> fields. Right now they are seen as independent from open/closed and
VersionOne
> couldn't care less about the status values. But by tying them together at
least
> loosely, it would greatly help users with keeping data accurate.
> > > What do you guys think? Do you have similar challenges? How do you
define
> your list of statuses and how do you get teams to keep them current?
-----Original Message-----
From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
Sent: Tuesday, November 11, 2008 12:35 PM
To: versionone-users@googlegroups.com
Subject: RE: automatic update of task/story status
My $.02: I kind of like having a separate status field. It lets you mark things as "In Progress" vs. "Not Started", and separates the issue of how much work is left.
It wouldn't give me great heartburn to lose that, but it seems less intuitive to me.
I think it does make sense to give more tie-in between the involved fields, to avoid things getting out of synch.
Jeff
-----Original Message-----
From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
Sent: Tuesday, November 11, 2008 1:32 PM
To: VersionOne-users
Subject: Re: automatic update of task/story status
I'd like to hear from others on this request...would this help your
teams?
-Luanne
On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> I would love to remove the status column altogether and just use the
> to do column as an indication of status (different than estimate = in
> progress, zero = done). I could have done this in my last group since
> we had a physical taskboard in our team room and would have only used
> V1 to track the tasks and burndown.
> In my current group I can't do this and these questions come up a lot
> because we are maturing into agile. People like the status more than
> the to do as a measurement of progress. We do our best to balance the
> issues and I try to keep focusing people on distance from DONE. It
> might be nice if the system could be configured to have status updates
> based on other event triggers, but I fear it only keeps people from
> understanding agile practices better as they rely on GANTT-like
> statusing.
> As for your 4 points, I completely ignore the last issue. If the
> story or task is closed, then that overrides whatever the status may
> or may not say (it helps that the to do is cleared in the process).
> On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > As background: We have our status values defined as open/in progress/blocked/complete.
> > Since human beings are not always primarily focused on keeping data fully up-to-date, we often see the following situations:
> > * The first person starts work on a new story (picks up a task & logs hours), but fails to change task status to "in progress".
> > * Task status is changed to "in progress", but the story status is not properly updated and remains at "open".
> > * People close tasks while their status is something other than "complete".
> > * Story status is set to "complete" while some tasks remain in a status other than "complete" and/or have to do > 0.
> > Common questions I get are: Why doesn't the system do this automatically? Or: Why does the system allow this to happen?
> > I understand that VersionOne doesn't "understand" what the statuses "mean" because it's a list of values that's custom and specific to the implementation. VersionOne only knows if something is open or closed.
> > Then again, with a little parameterization, one could address a number of these issues: If there were (optional) parameters like "in progress status: A" and "final status: B" or something, the system could automatically update task and story status to "A" as soon as hours are burned. Then, when tasks or stories are closed, the status could default to "B" (with the user being able to overwrite if necessary).
> > I understand that this would lead to a more interpretative view of the status fields. Right now they are seen as independent from open/closed and VersionOne couldn't care less about the status values. But by tying them together at least loosely, it would greatly help users with keeping data accurate.
> > What do you guys think? Do you have similar challenges? How do you define your list of statuses and how do you get teams to keep them current?
I doubt that Luanne's question was about removing the status column
from the system... my remark about removal is simply a reference to
the admin being able to configure it as hidden from view.
I believe she is asking if there is value in having the status field
automatically be updated by the change in other fields. For example,
should the status column be set to completed if the to do is set to a
zero value?
I see pro's and con's for this feature... I would possibly use it if
it was easily configurable, but it might cost more than its worth
compared to other things we might want V1 to build for us.
On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> If you removed "Status" from tasks how would the "Taskboard" work? We use and love the Taskboard.
> -----Original Message-----
> From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> Sent: Tuesday, November 11, 2008 12:35 PM
> To: versionone-users@googlegroups.com
> Subject: RE: automatic update of task/story status
> My $.02: I kind of like having a separate status field. It lets you mark things as "In Progress" vs. "Not Started", and separates the issue of how much work is left.
> It wouldn't give me great heartburn to lose that, but it seems less intuitive to me.
> I think it does make sense to give more tie-in between the involved fields, to avoid things getting out of synch.
> Jeff
> -----Original Message-----
> From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> Sent: Tuesday, November 11, 2008 1:32 PM
> To: VersionOne-users
> Subject: Re: automatic update of task/story status
> I'd like to hear from others on this request...would this help your
> teams?
> -Luanne
> On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > I would love to remove the status column altogether and just use the
> > to do column as an indication of status (different than estimate = in
> > progress, zero = done). I could have done this in my last group since
> > we had a physical taskboard in our team room and would have only used
> > V1 to track the tasks and burndown.
> > In my current group I can't do this and these questions come up a lot
> > because we are maturing into agile. People like the status more than
> > the to do as a measurement of progress. We do our best to balance the
> > issues and I try to keep focusing people on distance from DONE. It
> > might be nice if the system could be configured to have status updates
> > based on other event triggers, but I fear it only keeps people from
> > understanding agile practices better as they rely on GANTT-like
> > statusing.
> > As for your 4 points, I completely ignore the last issue. If the
> > story or task is closed, then that overrides whatever the status may
> > or may not say (it helps that the to do is cleared in the process).
> > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > As background: We have our status values defined as open/in progress/blocked/complete.
> > > Since human beings are not always primarily focused on keeping data fully up-to-date, we often see the following situations:
> > > * The first person starts work on a new story (picks up a task & logs hours), but fails to change task status to "in progress".
> > > * Task status is changed to "in progress", but the story status is not properly updated and remains at "open".
> > > * People close tasks while their status is something other than "complete".
> > > * Story status is set to "complete" while some tasks remain in a status other than "complete" and/or have to do > 0.
> > > Common questions I get are: Why doesn't the system do this automatically? Or: Why does the system allow this to happen?
> > > I understand that VersionOne doesn't "understand" what the statuses "mean" because it's a list of values that's custom and specific to the implementation. VersionOne only knows if something is open or closed.
> > > Then again, with a little parameterization, one could address a number of these issues: If there were (optional) parameters like "in progress status: A" and "final status: B" or something, the system could automatically update task and story status to "A" as soon as hours are burned. Then, when tasks or stories are closed, the status could default to "B" (with the user being able to overwrite if necessary).
> > > I understand that this would lead to a more interpretative view of the status fields. Right now they are seen as independent from open/closed and VersionOne couldn't care less about the status values. But by tying them together at least loosely, it would greatly help users with keeping data accurate.
> > > What do you guys think? Do you have similar challenges? How do you define your list of statuses and how do you get teams to keep them current?
-----Original Message-----
From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Kevin S.
Sent: Wednesday, November 12, 2008 9:43 AM
To: VersionOne-users
Subject: Re: automatic update of task/story status
I doubt that Luanne's question was about removing the status column
from the system... my remark about removal is simply a reference to
the admin being able to configure it as hidden from view.
I believe she is asking if there is value in having the status field
automatically be updated by the change in other fields. For example,
should the status column be set to completed if the to do is set to a
zero value?
I see pro's and con's for this feature... I would possibly use it if
it was easily configurable, but it might cost more than its worth
compared to other things we might want V1 to build for us.
On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> If you removed "Status" from tasks how would the "Taskboard" work? We use and love the Taskboard.
> -----Original Message-----
> From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> Sent: Tuesday, November 11, 2008 12:35 PM
> To: versionone-users@googlegroups.com
> Subject: RE: automatic update of task/story status
> My $.02: I kind of like having a separate status field. It lets you mark things as "In Progress" vs. "Not Started", and separates the issue of how much work is left.
> It wouldn't give me great heartburn to lose that, but it seems less intuitive to me.
> I think it does make sense to give more tie-in between the involved fields, to avoid things getting out of synch.
> Jeff
> -----Original Message-----
> From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> Sent: Tuesday, November 11, 2008 1:32 PM
> To: VersionOne-users
> Subject: Re: automatic update of task/story status
> I'd like to hear from others on this request...would this help your
> teams?
> -Luanne
> On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > I would love to remove the status column altogether and just use the
> > to do column as an indication of status (different than estimate = in
> > progress, zero = done). I could have done this in my last group since
> > we had a physical taskboard in our team room and would have only used
> > V1 to track the tasks and burndown.
> > In my current group I can't do this and these questions come up a lot
> > because we are maturing into agile. People like the status more than
> > the to do as a measurement of progress. We do our best to balance the
> > issues and I try to keep focusing people on distance from DONE. It
> > might be nice if the system could be configured to have status updates
> > based on other event triggers, but I fear it only keeps people from
> > understanding agile practices better as they rely on GANTT-like
> > statusing.
> > As for your 4 points, I completely ignore the last issue. If the
> > story or task is closed, then that overrides whatever the status may
> > or may not say (it helps that the to do is cleared in the process).
> > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > As background: We have our status values defined as open/in progress/blocked/complete.
> > > Since human beings are not always primarily focused on keeping data fully up-to-date, we often see the following situations:
> > > * The first person starts work on a new story (picks up a task & logs hours), but fails to change task status to "in progress".
> > > * Task status is changed to "in progress", but the story status is not properly updated and remains at "open".
> > > * People close tasks while their status is something other than "complete".
> > > * Story status is set to "complete" while some tasks remain in a status other than "complete" and/or have to do > 0.
> > > Common questions I get are: Why doesn't the system do this automatically? Or: Why does the system allow this to happen?
> > > I understand that VersionOne doesn't "understand" what the statuses "mean" because it's a list of values that's custom and specific to the implementation. VersionOne only knows if something is open or closed.
> > > Then again, with a little parameterization, one could address a number of these issues: If there were (optional) parameters like "in progress status: A" and "final status: B" or something, the system could automatically update task and story status to "A" as soon as hours are burned. Then, when tasks or stories are closed, the status could default to "B" (with the user being able to overwrite if necessary).
> > > I understand that this would lead to a more interpretative view of the status fields. Right now they are seen as independent from open/closed and VersionOne couldn't care less about the status values. But by tying them together at least loosely, it would greatly help users with keeping data accurate.
> > > What do you guys think? Do you have similar challenges? How do you define your list of statuses and how do you get teams to keep them current?
That one issue, that the To Do units do not get zeroed when the task
is set to Complete has come up with our developers. They are ready to
hack the code to fix it - in other words it's a big issue to
developers that are conditioned to remove duplication from _their_
code, to have well factored code. But then must use a tool that
requires them to *work*for*the*tool* and duplicate their work.
I can see that some groups would like to use these fields as
independent, that's OK with me (their just wrong - but they will wake
up one day). V1 could make this a system configuration value ON/OFF of
Complete equals zero To Do - feature.
[mailto:versionone-users@googlegroups.com] On Behalf Of Kevin S.
Sent: Wednesday, November 12, 2008 7:43 AM
To: VersionOne-users
Subject: Re: automatic update of task/story status
I doubt that Luanne's question was about removing the status column
from the system... my remark about removal is simply a reference to
the admin being able to configure it as hidden from view.
I believe she is asking if there is value in having the status field
automatically be updated by the change in other fields. For example,
should the status column be set to completed if the to do is set to a
zero value?
I see pro's and con's for this feature... I would possibly use it if
it was easily configurable, but it might cost more than its worth
compared to other things we might want V1 to build for us.
On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> If you removed "Status" from tasks how would the "Taskboard" work?
We use and love the Taskboard.
> -----Original Message-----
> From: versionone-users@googlegroups.com
[mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> Sent: Tuesday, November 11, 2008 12:35 PM
> To: versionone-users@googlegroups.com
> Subject: RE: automatic update of task/story status
> My $.02: I kind of like having a separate status field. It lets you
mark things as "In Progress" vs. "Not Started", and separates the
issue of how much work is left.
> It wouldn't give me great heartburn to lose that, but it seems less
intuitive to me.
> I think it does make sense to give more tie-in between the involved
fields, to avoid things getting out of synch.
> Jeff
> -----Original Message-----
> From: versionone-users@googlegroups.com
[mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> Sent: Tuesday, November 11, 2008 1:32 PM
> To: VersionOne-users
> Subject: Re: automatic update of task/story status
> I'd like to hear from others on this request...would this help your
> teams?
> -Luanne
> On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > I would love to remove the status column altogether and just use
the
> > to do column as an indication of status (different than estimate =
in
> > progress, zero = done). I could have done this in my last group
since
> > we had a physical taskboard in our team room and would have only
used
> > V1 to track the tasks and burndown.
> > In my current group I can't do this and these questions come up a
lot
> > because we are maturing into agile. People like the status more
than
> > the to do as a measurement of progress. We do our best to balance
the
> > issues and I try to keep focusing people on distance from DONE.
It
> > might be nice if the system could be configured to have status
updates
> > based on other event triggers, but I fear it only keeps people
from
> > understanding agile practices better as they rely on GANTT-like
> > statusing.
> > As for your 4 points, I completely ignore the last issue. If the
> > story or task is closed, then that overrides whatever the status
may
> > or may not say (it helps that the to do is cleared in the
process).
> > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > As background: We have our status values defined as open/in
progress/blocked/complete.
> > > Since human beings are not always primarily focused on keeping
data fully up-to-date, we often see the following situations:
> > > * The first person starts work on a new story (picks up a
task & logs hours), but fails to change task status to "in progress".
> > > * Task status is changed to "in progress", but the story
status is not properly updated and remains at "open".
> > > * People close tasks while their status is something other
than "complete".
> > > * Story status is set to "complete" while some tasks
remain in a status other than "complete" and/or have to do > 0.
> > > Common questions I get are: Why doesn't the system do this
automatically? Or: Why does the system allow this to happen?
> > > I understand that VersionOne doesn't "understand" what the
statuses "mean" because it's a list of values that's custom and
specific to the implementation. VersionOne only knows if something is
open or closed.
> > > Then again, with a little parameterization, one could address a
number of these issues: If there were (optional) parameters like "in
progress status: A" and "final status: B" or something, the system
could automatically update task and story status to "A" as soon as
hours are burned. Then, when tasks or stories are closed, the status
could default to "B" (with the user being able to overwrite if
necessary).
> > > I understand that this would lead to a more interpretative view
of the status fields. Right now they are seen as independent from
open/closed and VersionOne couldn't care less about the status values.
But by tying them together at least loosely, it would greatly help
users with keeping data accurate.
> > > What do you guys think? Do you have similar challenges? How do
you define your list of statuses and how do you get teams to keep them
current?
First off, thanks Kevin for clarifying what I was asking...you were
right on!
Based on the feedback, I'm submitting the following request based on
the original request from Rene:
"If there were (optional) parameters like "in progress status: A" and
"final status: B" or something, the system could automatically update
task and story status to "A" as soon as hours are burned. Then, when
tasks or stories are closed, the status could default to "B" (with the
user being able to overwrite if necessary)."
A Configurable update of Status based on the following:
If a task/story "ToDo" value is updated, default the status to
"A" (where A is configurable)
If a task/story "ToDo" value is set to Zero, default the status to
"B" (where B is configurable)
If a task/story is Closed, default the status to "C" (Where C is
configurable)
When you close a task today, it automatically zeros out the "ToDo"
values and prompts you to change the status. So if you have a default
selected, it would potentially populate the status and continue to pop
up the screen or not...I'll leave that up to the development team to
determine the best way to implement :)
-Luanne
On Nov 13, 8:32 pm, "David Koontz" <DKoo...@SolutionsIQ.com> wrote:
> That one issue, that the To Do units do not get zeroed when the task
> is set to Complete has come up with our developers. They are ready to
> hack the code to fix it - in other words it's a big issue to
> developers that are conditioned to remove duplication from _their_
> code, to have well factored code. But then must use a tool that
> requires them to *work*for*the*tool* and duplicate their work.
> I can see that some groups would like to use these fields as
> independent, that's OK with me (their just wrong - but they will wake
> up one day). V1 could make this a system configuration value ON/OFF of
> Complete equals zero To Do - feature.
> [mailto:versionone-users@googlegroups.com] On Behalf Of Kevin S.
> Sent: Wednesday, November 12, 2008 7:43 AM
> To: VersionOne-users
> Subject: Re: automatic update of task/story status
> I doubt that Luanne's question was about removing the status column
> from the system... my remark about removal is simply a reference to
> the admin being able to configure it as hidden from view.
> I believe she is asking if there is value in having the status field
> automatically be updated by the change in other fields. For example,
> should the status column be set to completed if the to do is set to a
> zero value?
> I see pro's and con's for this feature... I would possibly use it if
> it was easily configurable, but it might cost more than its worth
> compared to other things we might want V1 to build for us.
> On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> > If you removed "Status" from tasks how would the "Taskboard" work?
> We use and love the Taskboard.
> > -----Original Message-----
> > From: versionone-users@googlegroups.com
> [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> > Sent: Tuesday, November 11, 2008 12:35 PM
> > To: versionone-users@googlegroups.com
> > Subject: RE: automatic update of task/story status
> > My $.02: I kind of like having a separate status field. It lets you
> mark things as "In Progress" vs. "Not Started", and separates the
> issue of how much work is left.
> > It wouldn't give me great heartburn to lose that, but it seems less
> intuitive to me.
> > I think it does make sense to give more tie-in between the involved
> fields, to avoid things getting out of synch.
> > Jeff
> > -----Original Message-----
> > From: versionone-users@googlegroups.com
> [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> > Sent: Tuesday, November 11, 2008 1:32 PM
> > To: VersionOne-users
> > Subject: Re: automatic update of task/story status
> > I'd like to hear from others on this request...would this help your
> > teams?
> > -Luanne
> > On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > > I would love to remove the status column altogether and just use
> the
> > > to do column as an indication of status (different than estimate =
> in
> > > progress, zero = done). I could have done this in my last group
> since
> > > we had a physical taskboard in our team room and would have only
> used
> > > V1 to track the tasks and burndown.
> > > In my current group I can't do this and these questions come up a
> lot
> > > because we are maturing into agile. People like the status more
> than
> > > the to do as a measurement of progress. We do our best to balance
> the
> > > issues and I try to keep focusing people on distance from DONE.
> It
> > > might be nice if the system could be configured to have status
> updates
> > > based on other event triggers, but I fear it only keeps people
> from
> > > understanding agile practices better as they rely on GANTT-like
> > > statusing.
> > > As for your 4 points, I completely ignore the last issue. If the
> > > story or task is closed, then that overrides whatever the status
> may
> > > or may not say (it helps that the to do is cleared in the
> process).
> > > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > > As background: We have our status values defined as open/in
> progress/blocked/complete.
> > > > Since human beings are not always primarily focused on keeping
> data fully up-to-date, we often see the following situations:
> > > > * The first person starts work on a new story (picks up a
> task & logs hours), but fails to change task status to "in progress".
> > > > * Task status is changed to "in progress", but the story
> status is not properly updated and remains at "open".
> > > > * People close tasks while their status is something other
> than "complete".
> > > > * Story status is set to "complete" while some tasks
> remain in a status other than "complete" and/or have to do > 0.
> > > > Common questions I get are: Why doesn't the system do this
> automatically? Or: Why does the system allow this to happen?
> > > > I understand that VersionOne doesn't "understand" what the
> statuses "mean" because it's a list of values that's custom and
> specific to the implementation. VersionOne only knows if something is
> open or closed.
> > > > Then again, with a little parameterization, one could address a
> number of these issues: If there were (optional) parameters like "in
> progress status: A" and "final status: B" or something, the system
> could automatically update task and story status to "A" as soon as
> hours are burned. Then, when tasks or stories are closed, the status
> could default to "B" (with the user being able to overwrite if
> necessary).
> > > > I understand that this would lead to a more interpretative view
> of the status fields. Right now they are seen as independent from
> open/closed and VersionOne couldn't care less about the status values.
> But by tying them together at least loosely, it would greatly help
> users with keeping data accurate.
> > > > What do you guys think? Do you have similar challenges? How do
> you define your list of statuses and how do you get teams to keep them
> current?
-----Original Message-----
From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
Sent: Monday, November 17, 2008 3:27 PM
To: VersionOne-users
Cc: Supp...@versionone.com
Subject: Re: automatic update of task/story status
First off, thanks Kevin for clarifying what I was asking...you were
right on!
Based on the feedback, I'm submitting the following request based on
the original request from Rene:
"If there were (optional) parameters like "in progress status: A" and
"final status: B" or something, the system could automatically update
task and story status to "A" as soon as hours are burned. Then, when
tasks or stories are closed, the status could default to "B" (with the
user being able to overwrite if necessary)."
A Configurable update of Status based on the following:
If a task/story "ToDo" value is updated, default the status to
"A" (where A is configurable)
If a task/story "ToDo" value is set to Zero, default the status to
"B" (where B is configurable)
If a task/story is Closed, default the status to "C" (Where C is
configurable)
When you close a task today, it automatically zeros out the "ToDo"
values and prompts you to change the status. So if you have a default
selected, it would potentially populate the status and continue to pop
up the screen or not...I'll leave that up to the development team to
determine the best way to implement :)
-Luanne
On Nov 13, 8:32 pm, "David Koontz" <DKoo...@SolutionsIQ.com> wrote:
> That one issue, that the To Do units do not get zeroed when the task
> is set to Complete has come up with our developers. They are ready to
> hack the code to fix it - in other words it's a big issue to
> developers that are conditioned to remove duplication from _their_
> code, to have well factored code. But then must use a tool that
> requires them to *work*for*the*tool* and duplicate their work.
> I can see that some groups would like to use these fields as
> independent, that's OK with me (their just wrong - but they will wake
> up one day). V1 could make this a system configuration value ON/OFF of
> Complete equals zero To Do - feature.
> [mailto:versionone-users@googlegroups.com] On Behalf Of Kevin S.
> Sent: Wednesday, November 12, 2008 7:43 AM
> To: VersionOne-users
> Subject: Re: automatic update of task/story status
> I doubt that Luanne's question was about removing the status column
> from the system... my remark about removal is simply a reference to
> the admin being able to configure it as hidden from view.
> I believe she is asking if there is value in having the status field
> automatically be updated by the change in other fields. For example,
> should the status column be set to completed if the to do is set to a
> zero value?
> I see pro's and con's for this feature... I would possibly use it if
> it was easily configurable, but it might cost more than its worth
> compared to other things we might want V1 to build for us.
> On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> > If you removed "Status" from tasks how would the "Taskboard" work?
> We use and love the Taskboard.
> > -----Original Message-----
> > From: versionone-users@googlegroups.com
> [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> > Sent: Tuesday, November 11, 2008 12:35 PM
> > To: versionone-users@googlegroups.com
> > Subject: RE: automatic update of task/story status
> > My $.02: I kind of like having a separate status field. It lets you
> mark things as "In Progress" vs. "Not Started", and separates the
> issue of how much work is left.
> > It wouldn't give me great heartburn to lose that, but it seems less
> intuitive to me.
> > I think it does make sense to give more tie-in between the involved
> fields, to avoid things getting out of synch.
> > Jeff
> > -----Original Message-----
> > From: versionone-users@googlegroups.com
> [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> > Sent: Tuesday, November 11, 2008 1:32 PM
> > To: VersionOne-users
> > Subject: Re: automatic update of task/story status
> > I'd like to hear from others on this request...would this help your
> > teams?
> > -Luanne
> > On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > > I would love to remove the status column altogether and just use
> the
> > > to do column as an indication of status (different than estimate =
> in
> > > progress, zero = done). I could have done this in my last group
> since
> > > we had a physical taskboard in our team room and would have only
> used
> > > V1 to track the tasks and burndown.
> > > In my current group I can't do this and these questions come up a
> lot
> > > because we are maturing into agile. People like the status more
> than
> > > the to do as a measurement of progress. We do our best to balance
> the
> > > issues and I try to keep focusing people on distance from DONE.
> It
> > > might be nice if the system could be configured to have status
> updates
> > > based on other event triggers, but I fear it only keeps people
> from
> > > understanding agile practices better as they rely on GANTT-like
> > > statusing.
> > > As for your 4 points, I completely ignore the last issue. If the
> > > story or task is closed, then that overrides whatever the status
> may
> > > or may not say (it helps that the to do is cleared in the
> process).
> > > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > > As background: We have our status values defined as open/in
> progress/blocked/complete.
> > > > Since human beings are not always primarily focused on keeping
> data fully up-to-date, we often see the following situations:
> > > > * The first person starts work on a new story (picks up a
> task & logs hours), but fails to change task status to "in progress".
> > > > * Task status is changed to "in progress", but the story
> status is not properly updated and remains at "open".
> > > > * People close tasks while their status is something other
> than "complete".
> > > > * Story status is set to "complete" while some tasks
> remain in a status other than "complete" and/or have to do > 0.
> > > > Common questions I get are: Why doesn't the system do this
> automatically? Or: Why does the system allow this to happen?
> > > > I understand that VersionOne doesn't "understand" what the
> statuses "mean" because it's a list of values that's custom and
> specific to the implementation. VersionOne only knows if something is
> open or closed.
> > > > Then again, with a little parameterization, one could address a
> number of these issues: If there were (optional) parameters like "in
> progress status: A" and "final status: B" or something, the system
> could automatically update task and story status to "A" as soon as
> hours are burned. Then, when tasks or stories are closed, the status
> could default to "B" (with the user being able to overwrite if
> necessary).
> > > > I understand that this would lead to a more interpretative view
> of the status fields. Right now they are seen as independent from
> open/closed and VersionOne couldn't care less about the status values.
> But by tying them together at least loosely, it would greatly help
> users with keeping data accurate.
> > > > What do you guys think? Do you have similar challenges? How do
> you define your list of statuses and how do you get teams to keep them
> current?
This is an item of high interest for my team as well.
I have a question on something else you wrote: "So if you have a
default
selected, it would potentially populate the status and continue to
pop
up the screen or not..." how can we get a default value selected in
the status menu? When we close a story, the Status dropdown defaults
to blank. Or did you mean that one way to solve this issue was to
develope a way to set a default value within V1?
Thanks!
-Stef
On Nov 18, 11:12 am, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> -----Original Message-----
> From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> Sent: Monday, November 17, 2008 3:27 PM
> To: VersionOne-users
> Cc: Supp...@versionone.com
> Subject: Re:automaticupdateof task/story status
> First off, thanks Kevin for clarifying what I was asking...you were
> right on!
> Based on the feedback, I'm submitting the following request based on
> the original request from Rene:
> "If there were (optional) parameters like "in progress status: A" and
> "final status: B" or something, the system could automaticallyupdate
> task and story status to "A" as soon as hours are burned. Then, when
> tasks or stories are closed, the status could default to "B" (with the
> user being able to overwrite if necessary)."
> A Configurableupdateof Status based on the following:
> If a task/story "ToDo" value is updated, default the status to
> "A" (where A is configurable)
> If a task/story "ToDo" value is set to Zero, default the status to
> "B" (where B is configurable)
> If a task/story is Closed, default the status to "C" (Where C is
> configurable)
> When you close a task today, it automatically zeros out the "ToDo"
> values and prompts you to change the status. So if you have a default
> selected, it would potentially populate the status and continue to pop
> up the screen or not...I'll leave that up to the development team to
> determine the best way to implement :)
> -Luanne
> On Nov 13, 8:32 pm, "David Koontz" <DKoo...@SolutionsIQ.com> wrote:
> > That one issue, that the To Do units do not get zeroed when the task
> > is set to Complete has come up with our developers. They are ready to
> > hack the code to fix it - in other words it's a big issue to
> > developers that are conditioned to remove duplication from _their_
> > code, to have well factored code. But then must use a tool that
> > requires them to *work*for*the*tool* and duplicate their work.
> > I can see that some groups would like to use these fields as
> > independent, that's OK with me (their just wrong - but they will wake
> > up one day). V1 could make this a system configuration value ON/OFF of
> > Complete equals zero To Do - feature.
> > [mailto:versionone-users@googlegroups.com] On Behalf Of Kevin S.
> > Sent: Wednesday, November 12, 2008 7:43 AM
> > To: VersionOne-users
> > Subject: Re:automaticupdateof task/story status
> > I doubt that Luanne's question was about removing the status column
> > from the system... my remark about removal is simply a reference to
> > the admin being able to configure it as hidden from view.
> > I believe she is asking if there is value in having the status field
> > automatically be updated by the change in other fields. For example,
> > should the status column be set to completed if the to do is set to a
> > zero value?
> > I see pro's and con's for this feature... I would possibly use it if
> > it was easily configurable, but it might cost more than its worth
> > compared to other things we might want V1 to build for us.
> > On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> > > If you removed "Status" from tasks how would the "Taskboard" work?
> > We use and love the Taskboard.
> > > -----Original Message-----
> > > From: versionone-users@googlegroups.com
> > [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> > > Sent: Tuesday, November 11, 2008 12:35 PM
> > > To: versionone-users@googlegroups.com
> > > Subject: RE:automaticupdateof task/story status
> > > My $.02: I kind of like having a separate status field. It lets you
> > mark things as "In Progress" vs. "Not Started", and separates the
> > issue of how much work is left.
> > > It wouldn't give me great heartburn to lose that, but it seems less
> > intuitive to me.
> > > I think it does make sense to give more tie-in between the involved
> > fields, to avoid things getting out of synch.
> > > Jeff
> > > -----Original Message-----
> > > From: versionone-users@googlegroups.com
> > [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> > > Sent: Tuesday, November 11, 2008 1:32 PM
> > > To: VersionOne-users
> > > Subject: Re:automaticupdateof task/story status
> > > I'd like to hear from others on this request...would this help your
> > > teams?
> > > -Luanne
> > > On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > > > I would love to remove the status column altogether and just use
> > the
> > > > to do column as an indication of status (different than estimate =
> > in
> > > > progress, zero = done). I could have done this in my last group
> > since
> > > > we had a physical taskboard in our team room and would have only
> > used
> > > > V1 to track the tasks and burndown.
> > > > In my current group I can't do this and these questions come up a
> > lot
> > > > because we are maturing into agile. People like the status more
> > than
> > > > the to do as a measurement of progress. We do our best to balance
> > the
> > > > issues and I try to keep focusing people on distance from DONE.
> > It
> > > > might be nice if the system could be configured to have status
> > updates
> > > > based on other event triggers, but I fear it only keeps people
> > from
> > > > understanding agile practices better as they rely on GANTT-like
> > > > statusing.
> > > > As for your 4 points, I completely ignore the last issue. If the
> > > > story or task is closed, then that overrides whatever the status
> > may
> > > > or may not say (it helps that the to do is cleared in the
> > process).
> > > > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > > > As background: We have our status values defined as open/in
> > progress/blocked/complete.
> > > > > Since human beings are not always primarily focused on keeping
> > data fully up-to-date, we often see the following situations:
> > > > > * The first person starts work on a new story (picks up a
> > task & logs hours), but fails to change task status to "in progress".
> > > > > * Task status is changed to "in progress", but the story
> > status is not properly updated and remains at "open".
> > > > > * People close tasks while their status is something other
> > than "complete".
> > > > > * Story status is set to "complete" while some tasks
> > remain in a status other than "complete" and/or have to do > 0.
> > > > > Common questions I get are: Why doesn't the system do this
> > automatically? Or: Why does the system allow this to happen?
> > > > > I understand that VersionOne doesn't "understand" what the
> > statuses "mean" because it's a list of values that's custom and
> > specific to the implementation. VersionOne only knows if something is
> > open or closed.
> > > > > Then again, with a little parameterization, one could address a
> > number of these issues: If there were (optional) parameters like "in
> > progress status: A" and "final status: B" or something, the system
> > could automaticallyupdatetask and story status to "A" as soon as
> > hours are burned. Then, when tasks or stories are closed, the status
> > could default to "B" (with the user being able to overwrite if
> > necessary).
> > > > > I understand that this would lead to a more interpretative view
> > of the status fields. Right now they are seen as independent from
> > open/closed and VersionOne couldn't care less about the status values.
> > But by tying them together at least loosely, it would greatly help
> > users with keeping data accurate.
> > > > > What do you guys think? Do you have similar challenges? How do
> > you define your list of statuses and how do you get teams to keep them
> > current?
> This is an item of high interest for my team as well.
> I have a question on something else you wrote: "So if you have a
> default
> selected, it would potentially populate the status and continue to
> pop
> up the screen or not..." how can we get a default value selected in
> the status menu? When we close a story, the Status dropdown defaults
> to blank. Or did you mean that one way to solve this issue was to
> develope a way to set a default value within V1?
> Thanks!
> -Stef
> On Nov 18, 11:12 am, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > Sounds good to me! :)
> > Rene
> > -----Original Message-----
> > From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> > Sent: Monday, November 17, 2008 3:27 PM
> > To: VersionOne-users
> > Cc: Supp...@versionone.com
> > Subject: Re:automaticupdateof task/story status
> > First off, thanks Kevin for clarifying what I was asking...you were
> > right on!
> > Based on the feedback, I'm submitting the following request based on
> > the original request from Rene:
> > "If there were (optional) parameters like "in progress status: A" and
> > "final status: B" or something, the system could automaticallyupdate
> > task and story status to "A" as soon as hours are burned. Then, when
> > tasks or stories are closed, the status could default to "B" (with the
> > user being able to overwrite if necessary)."
> > A Configurableupdateof Status based on the following:
> > If a task/story "ToDo" value is updated, default the status to
> > "A" (where A is configurable)
> > If a task/story "ToDo" value is set to Zero, default the status to
> > "B" (where B is configurable)
> > If a task/story is Closed, default the status to "C" (Where C is
> > configurable)
> > When you close a task today, it automatically zeros out the "ToDo"
> > values and prompts you to change the status. So if you have a default
> > selected, it would potentially populate the status and continue to pop
> > up the screen or not...I'll leave that up to the development team to
> > determine the best way to implement :)
> > -Luanne
> > On Nov 13, 8:32 pm, "David Koontz" <DKoo...@SolutionsIQ.com> wrote:
> > > That one issue, that the To Do units do not get zeroed when the task
> > > is set to Complete has come up with our developers. They are ready to
> > > hack the code to fix it - in other words it's a big issue to
> > > developers that are conditioned to remove duplication from _their_
> > > code, to have well factored code. But then must use a tool that
> > > requires them to *work*for*the*tool* and duplicate their work.
> > > I can see that some groups would like to use these fields as
> > > independent, that's OK with me (their just wrong - but they will wake
> > > up one day). V1 could make this a system configuration value ON/OFF of
> > > Complete equals zero To Do - feature.
> > > [mailto:versionone-users@googlegroups.com] On Behalf Of Kevin S.
> > > Sent: Wednesday, November 12, 2008 7:43 AM
> > > To: VersionOne-users
> > > Subject: Re:automaticupdateof task/story status
> > > I doubt that Luanne's question was about removing the status column
> > > from the system... my remark about removal is simply a reference to
> > > the admin being able to configure it as hidden from view.
> > > I believe she is asking if there is value in having the status field
> > > automatically be updated by the change in other fields. For example,
> > > should the status column be set to completed if the to do is set to a
> > > zero value?
> > > I see pro's and con's for this feature... I would possibly use it if
> > > it was easily configurable, but it might cost more than its worth
> > > compared to other things we might want V1 to build for us.
> > > On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> > > > If you removed "Status" from tasks how would the "Taskboard" work?
> > > We use and love the Taskboard.
> > > > -----Original Message-----
> > > > From: versionone-users@googlegroups.com
> > > [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> > > > Sent: Tuesday, November 11, 2008 12:35 PM
> > > > To: versionone-users@googlegroups.com
> > > > Subject: RE:automaticupdateof task/story status
> > > > My $.02: I kind of like having a separate status field. It lets you
> > > mark things as "In Progress" vs. "Not Started", and separates the
> > > issue of how much work is left.
> > > > It wouldn't give me great heartburn to lose that, but it seems less
> > > intuitive to me.
> > > > I think it does make sense to give more tie-in between the involved
> > > fields, to avoid things getting out of synch.
> > > > Jeff
> > > > -----Original Message-----
> > > > From: versionone-users@googlegroups.com
> > > [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> > > > Sent: Tuesday, November 11, 2008 1:32 PM
> > > > To: VersionOne-users
> > > > Subject: Re:automaticupdateof task/story status
> > > > I'd like to hear from others on this request...would this help your
> > > > teams?
> > > > -Luanne
> > > > On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > > > > I would love to remove the status column altogether and just use
> > > the
> > > > > to do column as an indication of status (different than estimate =
> > > in
> > > > > progress, zero = done). I could have done this in my last group
> > > since
> > > > > we had a physical taskboard in our team room and would have only
> > > used
> > > > > V1 to track the tasks and burndown.
> > > > > In my current group I can't do this and these questions come up a
> > > lot
> > > > > because we are maturing into agile. People like the status more
> > > than
> > > > > the to do as a measurement of progress. We do our best to balance
> > > the
> > > > > issues and I try to keep focusing people on distance from DONE.
> > > It
> > > > > might be nice if the system could be configured to have status
> > > updates
> > > > > based on other event triggers, but I fear it only keeps people
> > > from
> > > > > understanding agile practices better as they rely on GANTT-like
> > > > > statusing.
> > > > > As for your 4 points, I completely ignore the last issue. If the
> > > > > story or task is closed, then that overrides whatever the status
> > > may
> > > > > or may not say (it helps that the to do is cleared in the
> > > process).
> > > > > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > > > > As background: We have our status values defined as open/in
> > > progress/blocked/complete.
> > > > > > Since human beings are not always primarily focused on keeping
> > > data fully up-to-date, we often see the following situations:
> > > > > > * The first person starts work on a new story (picks up a
> > > task & logs hours), but fails to change task status to "in progress".
> > > > > > * Task status is changed to "in progress", but the story
> > > status is not properly updated and remains at "open".
> > > > > > * People close tasks while their status is something other
> > > than "complete".
> > > > > > * Story status is set to "complete" while some tasks
> > > remain in a status other than "complete" and/or have to do > 0.
> > > > > > Common questions I get are: Why doesn't the system do this
> > > automatically? Or: Why does the system allow this to happen?
> > > > > > I understand that VersionOne doesn't "understand" what the
> > > statuses "mean" because it's a list of values that's custom and
> > > specific to the implementation. VersionOne only knows if something is
> > > open or closed.
> > > > > > Then again, with a little parameterization, one could address a
> > > number of these issues: If there were (optional) parameters like "in
> > > progress status: A" and "final status: B" or something, the system
> > > could automaticallyupdatetask and story status to "A" as soon as
> > > hours are burned. Then, when tasks or stories are closed, the status
> > > could default to "B" (with the user being able to overwrite if
> > > necessary).
> > > > > > I understand that this would lead to a more interpretative view
> > > of the status fields. Right now they are seen as independent from
> > > open/closed and VersionOne couldn't care less about the status values.
> > > But by tying them together at least loosely, it would greatly help
> > > users with keeping data accurate.
> > > > > > What do you guys think? Do you have similar challenges? How do
> > > you define your list of statuses and how do you get teams to keep them
> > > current?
> > > > > > Thanks,
> > > > > > René- Hide quoted text -
> > > > > - Show quoted text -- Hide quoted text -
Transitions are shortcuts that allow you to impact multiple values with a single action. The transitions show up as options in the action menus on grids and the Taskboard / Testboard pages. New transitions are:
Sign Up - assign me as owner and optionally update status Quick Close - close the item and optionally update status
A default set of status updates are applied when Transitions are enabled. System Administrators have the ability to modify the status values for each type of update, including the ability to make no change at all. Transitions are automatically enabled when systems are upgraded, so be sure to review the configured Status values to ensure they are appropriate for your organization.
-----Original Message-----
From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
Sent: Monday, December 22, 2008 10:33 AM
To: VersionOne-users
Subject: Re: automatic update of task/story status
The goal would be to also set the status of a story when closing via
an admin option.
-Luanne
On Dec 17, 5:11 pm, Stef <SDiCarr...@gmail.com> wrote:
> This is an item of high interest for my team as well.
> I have a question on something else you wrote: "So if you have a
> default
> selected, it would potentially populate the status and continue to
> pop
> up the screen or not..." how can we get a default value selected in
> the status menu? When we close a story, the Status dropdown defaults
> to blank. Or did you mean that one way to solve this issue was to
> develope a way to set a default value within V1?
> Thanks!
> -Stef
> On Nov 18, 11:12 am, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > Sounds good to me! :)
> > Rene
> > -----Original Message-----
> > From: versionone-users@googlegroups.com [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> > Sent: Monday, November 17, 2008 3:27 PM
> > To: VersionOne-users
> > Cc: Supp...@versionone.com
> > Subject: Re:automaticupdateof task/story status
> > First off, thanks Kevin for clarifying what I was asking...you were
> > right on!
> > Based on the feedback, I'm submitting the following request based on
> > the original request from Rene:
> > "If there were (optional) parameters like "in progress status: A" and
> > "final status: B" or something, the system could automaticallyupdate
> > task and story status to "A" as soon as hours are burned. Then, when
> > tasks or stories are closed, the status could default to "B" (with the
> > user being able to overwrite if necessary)."
> > A Configurableupdateof Status based on the following:
> > If a task/story "ToDo" value is updated, default the status to
> > "A" (where A is configurable)
> > If a task/story "ToDo" value is set to Zero, default the status to
> > "B" (where B is configurable)
> > If a task/story is Closed, default the status to "C" (Where C is
> > configurable)
> > When you close a task today, it automatically zeros out the "ToDo"
> > values and prompts you to change the status. So if you have a default
> > selected, it would potentially populate the status and continue to pop
> > up the screen or not...I'll leave that up to the development team to
> > determine the best way to implement :)
> > -Luanne
> > On Nov 13, 8:32 pm, "David Koontz" <DKoo...@SolutionsIQ.com> wrote:
> > > That one issue, that the To Do units do not get zeroed when the task
> > > is set to Complete has come up with our developers. They are ready to
> > > hack the code to fix it - in other words it's a big issue to
> > > developers that are conditioned to remove duplication from _their_
> > > code, to have well factored code. But then must use a tool that
> > > requires them to *work*for*the*tool* and duplicate their work.
> > > I can see that some groups would like to use these fields as
> > > independent, that's OK with me (their just wrong - but they will wake
> > > up one day). V1 could make this a system configuration value ON/OFF of
> > > Complete equals zero To Do - feature.
> > > [mailto:versionone-users@googlegroups.com] On Behalf Of Kevin S.
> > > Sent: Wednesday, November 12, 2008 7:43 AM
> > > To: VersionOne-users
> > > Subject: Re:automaticupdateof task/story status
> > > I doubt that Luanne's question was about removing the status column
> > > from the system... my remark about removal is simply a reference to
> > > the admin being able to configure it as hidden from view.
> > > I believe she is asking if there is value in having the status field
> > > automatically be updated by the change in other fields. For example,
> > > should the status column be set to completed if the to do is set to a
> > > zero value?
> > > I see pro's and con's for this feature... I would possibly use it if
> > > it was easily configurable, but it might cost more than its worth
> > > compared to other things we might want V1 to build for us.
> > > On Nov 11, 2:15 pm, "Stout, Michael" <Michael.St...@sabre.com> wrote:
> > > > If you removed "Status" from tasks how would the "Taskboard" work?
> > > We use and love the Taskboard.
> > > > -----Original Message-----
> > > > From: versionone-users@googlegroups.com
> > > [mailto:versionone-users@googlegroups.com] On Behalf Of Jeff Pek
> > > > Sent: Tuesday, November 11, 2008 12:35 PM
> > > > To: versionone-users@googlegroups.com
> > > > Subject: RE:automaticupdateof task/story status
> > > > My $.02: I kind of like having a separate status field. It lets you
> > > mark things as "In Progress" vs. "Not Started", and separates the
> > > issue of how much work is left.
> > > > It wouldn't give me great heartburn to lose that, but it seems less
> > > intuitive to me.
> > > > I think it does make sense to give more tie-in between the involved
> > > fields, to avoid things getting out of synch.
> > > > Jeff
> > > > -----Original Message-----
> > > > From: versionone-users@googlegroups.com
> > > [mailto:versionone-users@googlegroups.com] On Behalf Of Luanne
> > > > Sent: Tuesday, November 11, 2008 1:32 PM
> > > > To: VersionOne-users
> > > > Subject: Re:automaticupdateof task/story status
> > > > I'd like to hear from others on this request...would this help your
> > > > teams?
> > > > -Luanne
> > > > On Nov 4, 11:27 am, "Kevin S." <ksch...@gmail.com> wrote:
> > > > > I would love to remove the status column altogether and just use
> > > the
> > > > > to do column as an indication of status (different than estimate =
> > > in
> > > > > progress, zero = done). I could have done this in my last group
> > > since
> > > > > we had a physical taskboard in our team room and would have only
> > > used
> > > > > V1 to track the tasks and burndown.
> > > > > In my current group I can't do this and these questions come up a
> > > lot
> > > > > because we are maturing into agile. People like the status more
> > > than
> > > > > the to do as a measurement of progress. We do our best to balance
> > > the
> > > > > issues and I try to keep focusing people on distance from DONE.
> > > It
> > > > > might be nice if the system could be configured to have status
> > > updates
> > > > > based on other event triggers, but I fear it only keeps people
> > > from
> > > > > understanding agile practices better as they rely on GANTT-like
> > > > > statusing.
> > > > > As for your 4 points, I completely ignore the last issue. If the
> > > > > story or task is closed, then that overrides whatever the status
> > > may
> > > > > or may not say (it helps that the to do is cleared in the
> > > process).
> > > > > On Nov 3, 4:41 pm, "Rene Rosendahl" <rrosend...@kbb.com> wrote:
> > > > > > As background: We have our status values defined as open/in
> > > progress/blocked/complete.
> > > > > > Since human beings are not always primarily focused on keeping
> > > data fully up-to-date, we often see the following situations:
> > > > > > * The first person starts work on a new story (picks up a
> > > task & logs hours), but fails to change task status to "in progress".
> > > > > > * Task status is changed to "in progress", but the story
> > > status is not properly updated and remains at "open".
> > > > > > * People close tasks while their status is something other
> > > than "complete".
> > > > > > * Story status is set to "complete" while some tasks
> > > remain in a status other than "complete" and/or have to do > 0.
> > > > > > Common questions I get are: Why doesn't the system do this
> > > automatically? Or: Why does the system allow this to happen?
> > > > > > I understand that VersionOne doesn't "understand" what the
> > > statuses "mean" because it's a list of values that's custom and
> > > specific to the implementation. VersionOne only knows if something is
> > > open or closed.
> > > > > > Then again, with a little parameterization, one could address a
> > > number of these issues: If there were (optional) parameters like "in
> > > progress status: A" and "final status: B" or something, the system
> > > could automaticallyupdatetask and story status to "A" as soon as
> > > hours are burned. Then, when tasks or stories are closed, the status
> > > could default to "B" (with the user being able to overwrite if
> > > necessary).
> > > > > > I understand that this would lead to a more interpretative view
> > > of the status fields. Right now they are seen as independent from
> > > open/closed and VersionOne couldn't care less about the status values.
> > > But by tying them together at least
Luanne, Could you elaborate on this? I have tried it several ways and still have multiple fields for the same drop downs for my stories, defects and tasks.
----- Original Message ----- From: Anne Larsen To: versionone-users@googlegroups.com Sent: Tuesday, January 31, 2012 2:55 AM Subject: Re: Duplicate custom fields?
Luanne, Could you elaborate on this? I have tried it several ways and still have multiple fields for the same drop downs for my stories, defects and tasks.
Thanks Anne
-- You received this message because you are subscribed to the Google Groups "VersionOne-users" group. To view this discussion on the web visit https://groups.google.com/d/msg/versionone-users/-/L5w1ojUuHFIJ. To post to this group, send email to versionone-users@googlegroups.com. To unsubscribe from this group, send email to versionone-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/versionone-users?hl=en.
You can do this via the Custom Columns tab. Select the Assign Field option and choose the additional column you created. Once you assign it you can then delete the column you just assigned.
-Luanne
On Nov 4, 11:30 am, <Jim.A...@bentley.com>; wrote:
> Is there any way to assign the same custom field to both a story and a > defect? Otherwise I have to add them in both places and end up with 2 > columns for the same field when stories and defects are displayed > together:
> Thanks,
> Jim
On Tue, Jan 31, 2012 at 11:48 AM, Hesself <hess...@013.net> wrote: > ** > What was the original question?
> ----- Original Message ----- > *From:* Anne Larsen <alarsen2...@gmail.com> > *To:* versionone-users@googlegroups.com > *Sent:* Tuesday, January 31, 2012 2:55 AM > *Subject:* Re: Duplicate custom fields?
> Luanne, > Could you elaborate on this? I have tried it several ways and still have > multiple fields for the same drop downs for my stories, defects and tasks.
> Thanks > Anne
> -- > You received this message because you are subscribed to the Google Groups > "VersionOne-users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/versionone-users/-/L5w1ojUuHFIJ. > To post to this group, send email to versionone-users@googlegroups.com. > To unsubscribe from this group, send email to > versionone-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/versionone-users?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "VersionOne-users" group. > To post to this group, send email to versionone-users@googlegroups.com. > To unsubscribe from this group, send email to > versionone-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/versionone-users?hl=en.
