|
Key Takeaways
|
|
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.
Eric Nash
Eric Nash is an Agile expert and Rally resident advisor who is happiest when he can coach and share his passion with others, whether it’s working on digital and Agile transformations, junior golf or fishing. When not on the water he works with organizations in industries from manufacturing to publishing to defense...
Other resources you might be interested in
Your Root Cause Analysis is Flawed by Design
Discover the critical flaw in your troubleshooting approaches. Employ network observability to extend your visibility across the entire service delivery path.
Whose Fault Is It When the Cloud Fails? Does It Matter?
In today's interconnected environments, it is vital to gain visibility into networks you don't own, including internet and cloud provider infrastructures.
The Future of Network Configuration Management is Unified, Not Uncertain
Read this post and discover how Broadcom is breathing new life into the trusted Voyence NCM, making it a core part of its unified observability platform.
Rally Office Hours: October 9, 2025
Discover Rally's new AI-powered Team Health Widget for flow metrics and drill-downs on feature charts. Plus, get updates on WIP limits and future enhancements.
AAI - Navigating the Interface and Refining Data Views
This course introduces you to AAI’s interface and shows you how to navigate efficiently, work with tables, and refine large datasets using search and filter tools.
Rally Office Hours: October 16, 2025
Rally's new AI-driven feature automates artifact breakdown - transforming features into stories or stories into tasks - saving time and ensuring consistency.
What’s New in Network Observability for Fall 2025
Discover how the Fall 2025 release of Network Observability by Broadcom introduces powerful new capabilities, elevating your insights and automation.
Modernizing Monitoring in a Converged IT-OT Landscape
The energy sector is shifting, driven by rapid grid modernization and the convergence of IT and OT networks. Traditional monitoring tools fall short.
Your network isn't infrastructure anymore. It's a product.
See why it’s time to stop managing infrastructure and start treating the network as your company's most critical product. Justify investments and prove ROI.