A lot of our customers use workflow branching to manage different types of issues
with different processes. Probably the most common example I hear of is simplifying the feature request workflow, instead of using what is typically a pretty detailed process for ensuring defects and issues are properly resolved.
First step is to setup workflow branching, which is detailed in this blog post
. Once you have your branches defined, the next step is to build out each branch's path. In this example, I'm going to create a pretty basic workflow process to handle feature requests.
Create your workflow states
To get started, go to Tools > Administration > Workflow. Remember that states are the stops in our process (squares in the above diagram). Creating the workflow states is really easy, just go to the States tab and click Add to create a new state. Every state except for the Closed and Released states should have the Attribute set to Open, and then set it to Closed for those two.
Create your events
Events move the feature request from state to state. When creating events, pick your resulting state from the drop-down and you typically want to set Assignments to "Event results in a new assignment" to allow the feature request to be assigned to a user as part of the state transition. In the Send for Review state below for example, we want to assign the request to the product owner when it's sent for review
(or if you have a CCB type of committee that reviews and approves/rejects change requests). That can be done with an automation rule, under Tools > Administration > Automation Rules.
A couple of more advanced options on workflow events include custom fields and flagging associated items as suspect. One custom field you might use would be to capture the release information when applying the Assign to Release event. To create custom field, just click over to the Custom tab on the event creation dialog and create a new field. To ensure the data is captured by users, go to Tools > Administration > Required Fields & Default Values to set that new custom field as required.
Create tracked requirements from a feature requestMarking dependent items as suspect
is huge in staying on top of changes to upstream artifacts. So in this workflow, let's say that when the request is assigned to a release you also create a requirement from that feature request. Once that's done, the feature request is pretty much "finished" and actual implementation work proceeds against the requirement. Normally any changes would be made to the requirements, but let's say that the CCB comes back and decides that the feature request doesn't make any sense now that Microsoft has announced the new XBox One
(no point in supporting the old XBox!) So they reject the FR (you would need a transition rule change to allow this, the diagram above doesn't allow rejections once it's been approved) but the development team never gets the message because they're working off of the requirement at this point!! So that's time wasted, unless on the Rejected event you check the "Include option to mark dependent items as suspect" box. If you set that up, then the CCB could check that box when they reject the FR and that would automatically flag the associated requirement that something upstream has changed. With that flag set the team would know to go back and see what's been changed, notice that it's been rejected, and could drop that requirement from the current sprint without wasting any more time working on it.
Setup transition rules
The last step in the process is to setup the transition rules, which define what states are connected to which events.