This is always a source of controversy, but alas the fact remains in our large globally distributed agile adoption, we need to insure misssteps by users don't cause inaccurate reporting and understandings. One example, if a story has no status, and someone starts a task for that story, the story status does not update to In Progress, when a task is set to In Progress, Completed, etc. I know task and story statuses are customizable, so a very flexible transition rule interface would be needed to manage this. in this above case, if a task is set to anything but no status or Completed, then the story should be moved to In Progress. Another example would be people who work from the My Work screen and update the status on thier tasks and stories rather than using the main taskboard. We run into folks setting a story done, when there are tasks outstanding for others in the same story. We would want to prevent them from changing a story to Done in this case. Yes, I know that that is a fault of the team, coaching and training, not the V1 product, but until our teams become truely agile, we are faced with this challange.
by: Tom W. | over a year ago | Tracking
Comments
Great idea... I believe VersionOne plans on expanding transitions, but we should keep providing ideas for them to do so!
All excellent ideas. Ideally VersionOne would support workflows as their own concept, rather than just another field on an issue. They must be customizable (per project even), and it must be possible to associate rules with the transitions (e.g. "do this transition if someone logs time").
An example that I would like to see is that if the the remainig hours goes to 0, then the item gets closed and vice versa.
I agree also. There needs to be some validation to ensure consistency between the states of backlog items, tasks, and tests. The transition rule interface needs to be flexible enough to allow each organization to set its own policies regarding the status of tasks, backlog items, tests, etc.
I do not agree that this is simply a training issue. That may suffice in small projects with small teams, but this kind of validation is absolutely essential in a true enterprise level tool.
This is needed. But for VersionOne to get a good idea of how it will be used, people need to tell them how they want to use it. Make more comments, give more examples. Here's mine:
WHEN [any field] IS [changed in any way (e.g. record updated)] DO [...]
WHEN [field] IS [changed (in any way)] DO [...]
WHEN [field] IS [cleared (set to null)] DO [...]
WHEN [field] IS [set to this value...] DO [...]
WHEN [field] IS [set to this value]
AND [other field] IS [set to this other value]
THEN DO [...] # in other words, allow rules to have multiple conditions
DO actions: (can have multiple actions in one rule)
Send an email to user making change.
Send an email to asset owner.
Send an email to particular user (e.g. administrator or QA person)
For [current record | parent asset | child assets]:
Make a field required
Make a field not-required
Clear the value of a field
Set the value of a field to a fixed value
Set the value of a field to a calculated value based on some formula dependent on other fields
Close the item
Reopen the item ? maybe ?
As a VersionOne Product Owner I would like the status on the Backlog Item or Defect to automatically go to “In Progress” whenever one or more tasks go to the In Progress status so that I don’t have to remember to go and manually update the status on all backlog items in the sprint. The "generic" ability to create custom transitions is perhaps less important to us that the status-based transition.
This feature would benefit all of our Scrum Masters and Team members (hundreds of users), as well as Product Owners who are monitoring their backlog from the Release Plannign View.
As a version one scrum master I would like to have a custom field which is the sum of 3 other fields. This allows me to create a custom ranking based on 3 different criteria, complexity, cost, and customer pain so that I can then sort by that field in order to figure out which request we should focus on next.
I would want the sum to be automatically updated when the other fields were modified.
Here's some examples of how we'd use the rules:
If task is set to In progress or Complete, update BL or Defect status with 'In progress'.
If BL or Defect status is set to 'Peer Review', update all task statuses to 'Complete'.
If BL or Defect status is set to 'Ready for Testing', update all Tests which are Null or 'Failed' to 'Ready for Testing'.
If Test Status is set to 'Failed', update BL or Defect status to 'Needs Rework'.
If BL or Defect status is set to 'Done', update all Tests to 'Passed', except those containing the status 'Closed', update all Tests to Complete, except those containing the status 'Not Needed'
This is of course using some of our custom workflow statuses, and requires exceptions.
The ability to set a rule for status when a user logs time, is potentially useful, however, we lot the time it takes to create the task or test on some occasions where we haven't actually begun the task or test. Thus an optional rule is appealling here.
This is even more of an issue with the security model--where the Developer role cannot update a Backlog (which is fine, except when trying to change status of the Backlog). There needs to be something that allows the status to be modified without direct intervention from someone with higher-than-Developer access.
I voted for the idea of having configurable transition of Backlog status field based on its tasks.
Our case is quite simple:
When the BL's first task is moved to In Progress, change the BL status to In Progress.
When the BL's last task is completed, change the BL status to Done.
Enable users with appropriate permissions to manually change the status.
Of course that the conditions, dependencies and permissions should be configurable to match the way the organization works.
It will be nice of course that the asset that control the status will be configurable as well. For us it is tasks and tests.
This would be really great if a story can go in progress when there is at least one task in that state.
Something simple like a toggle on a state that shows whether it is close-able would be nice. We routinely see people close out stories that are not in Done state.
It would really help with compliance if there were less clicks to get everything done. With higher compliance, would have the added benefit of everyone in the organization having no doubt as to an item's status.
See https://ideaspace.versionone.com/default/Idea/Detail/390, which is in the Fall release
I think the most basic functionality would have the Story status sync to the "lowest" of the task statuses (with the exception of in progress).
Example:
Say statuses are: Ready, In Progress, In Testing, Complete
Say there are 3 tasks in the story.
When the first task is moved to In Progress, the story is also moved to In Progress.
When the first task is moved to In Testing, and the second task is moved to In Progress, the story stays In Progress. (I acknowledge that this could leave a possibility of having one task in In Testing and the others in Ready making the story appear to be Ready, but that should only be temporary as one shouldn't complete one task then move on to other stories).
When all three tasks have been moved to In Testing, the story is now updated to In Testing.
No change when tasks 1 and 2 are moved to Complete, but when the final task is moved to Complete, the story is also moved to Complete.
That, to me, seems like a basic implementation that would cover a lot of needs without requiring an interface for much customization. Just a few more options of methods to sync would be a great improvement.
The current implementation is borderline nonsensical. Tying any movement of tasks to a specific status makes no sense to us outside of the very limited "moving a task indicates it is In Progress, so we can update the story to that status when something is moved". Even that is hard to justify, as this means that if I have a task that is considered not required so I move it to complete, suddenly the story is In Progress, which is not representative of the actual status of the story.
More flexible transitions would definitely be appreciated. The current functionality doesn't enable a Task to change the story status to a value, i.e. In Process, and a Test to change the story status to another, i.e. Testing. Additionally, having the functionality to trigger a status change on the first Task or Test to change vs. when all the Task or Tests have been closed or set to a specific status would be helpful. For example, when all Tasks have been set to Complete, update the Story's status to Ready for Testing. Transitions need to be supported at the Portfolio Item level as well.
This is needed as we create team flows
Being able to create custom team workflows is helpful, but we also need the ability to create custom transitions for those workflows.
I think that they don't have to actually transition the story to In Progress if a task starts (for example). I'd be OK with them just giving some visual indicator that says, "Hey, I think I should be in Progress? Do you agree?" Then give a quick/fast/single action that makes it so. So an actual person is confirming the system's suspicion, but at the end of the day, you need a member's ID on that move, not auto-moving. That's tricky to get everyone to understand in which conditions things get moved around without human intervention.
Like below, you just see it and click the little arrow icon to advance the story's status.
___________________________________________
|Story 12345 [Tasks started -->] |
|