We actively encourage Rally customers to provide feedback, and we value and act on that input. One consistent theme we receive feedback on is around the topic of improving the data in the system. More specifically, customers want to know how they can improve reporting and auditing of their data, particularly as work moves across the different states in the product lifecycle.
In response to this feedback, we added the Work Rules capability. With this capability, you can improve the consistency of your information and analytics in Rally by making fields either required or read-only under certain conditions. Here are a few examples:
- Make the Resolution field for a defect required before work on that defect can be considered complete.
- Make the Investment Category field required on a Feature before development can start on that feature.
- Prevent changes to Preliminary Estimate after development starts on a Feature.
We can do all of these things and more using the powerful Work Rules capability in Rally.
As an example, let’s create the defect Resolution field Work Rule described above to improve defect handling.
Example: Make the Resolution field required for Defects before we can call the work complete
Creating Work Rules requires at least Project administrator permissions, which are commonly assigned to a Scrum Master or other members of a team. For this example, let’s start in Project Settings > Work Rules for our Green Team.
If we had any work rules already scoped to this project and its children, then we’d see them listed here. We can click the Show Inherited toggle to see rules inherited from a parent project or from the entire workspace.
Now, let’s click the Create Work Rule button. The first thing that we need to decide is whether we want to make one or more fields required or whether we want to do the reverse and make them read-only under certain conditions. In this example, we’re going to make a field required.
The next thing we need to do is to select whether this rule applies to Work Items like Stories or Defects, or to Portfolio Items like Initiatives or Features. Let’s also give the rule a name that will serve as the message when someone breaks this rule.
The rule can apply to this project or team only, or to this project and its children. Since the Green Team in this example is a leaf-level project, we can ignore this. Now let’s choose the work item type, in this case Defect.
Now we specify our conditions, which are set for both Schedule State and Flow State. In this case, since we want to wait until we move a Defect to a done state before enforcing the rule, we’ll start from the right and select Accepted first. If the other Schedule States auto-select, you can just de-select them and start again from the right. Since the Done and Deployed flow states both map to Accepted for this team, they’re both selected automatically and we’ll keep them that way.
We also need to select which field or fields the rule applies to. We’ll select Resolution and click the Apply button. We then specify whether we want to simply warn the user when the rule is broken or to prevent the change. For this rule, we’ll select Error to prevent the change, and then click Create to save the rule.
Now if we go to the Team Board and Show Work Rules, we’ll see this and any other rules that apply to this team. If a user tries to move a Defect to Done or Deployed without specifying resolution, the rule is triggered.
Note: Work Rules can be set at either the Project or Workspace level. As part of our example, I’ve already created a Required and a Read-only rule for Features in this workspace. We can see them both by showing work rules on the Portfolio Kanban and by toggling the “Show Inherited” switch to ON when viewing the Work Rules page for this project.
In conclusion, you now have a good idea of what Work Rules can do to help enforce process decisions and improve data quality in your organization. If you’d like more help on Work Rules, just click the Help question mark icon on any Rally page and type “work rules” in the search box.
