Automations are accessible to all Fibery plans without limitations.
Check out our webinar for detailed explanations and join our community to dive deeper into real cases!
Let's check, how can Fibery Automation Rules improve and automate your Software Development process.
Cases:
Create new sprints automatically 🏃♀️
Automatically mark Sprints as Done ✔
Change Bug priority based on the number of complaints 🐛
Change Story priority when Due Date is coming ⌚
Assign QA when Bug is ready for testing 🦐
When the feature is ready set all stories and bugs as Done 🚀
Split iterations - move all undone bugs and sprints from one sprint to another
Document template / default describtion for Bugs
Sprint Planning
Create new sprints automatically 🏃♀️
Expected result: new Sprint will be created in 1 week after the previous ended with two weeks duration
Rule:
Formula:
Noted!
you have to add a 1:1 relations between Sprint and Sprint Database. So each Sprint would have a Previous Sprint and Next Sprint
Here is a pro guide on how to set Duration formulas in Fibery
Automatically mark Sprints as Done ✔
Expected result: Sprint will be moved to Done State when its End date is Today.
Rule:
Prioritizing
Change Bug priority based on the number of complaints 🐛
Expected result: when more than 2 users reported the bug - change Priority to Urgent
Rule:
Noted!
you have to add a # of complaints Formula to the Bug Database.
References.Count()you also need to have a Priority Field. Let it be a Single Select
collecting Bug reports is a part of a feedback process - check our blog post about it
Change Story priority when Due Date is coming ⌚
Expected result: when the Due Date for the Story is coming - Notify Assignee and change Priority to Urgent
Rule:
Noted!
you have to add the Due Date field (single Date without Duration)
you also need to have a Priority Field. Let it be a Single Select
Workflow Improvements
Assign QA when Bug is ready for testing 🦐
Expected result: When Bug or Story moves to the "To Test" State - assign QA
Rule:
If you have many QA ✨ - you can make an alternative rule - Notify all QA in your company and let them decide, who will take the bug
If you have too many QA and what to notify the one, who has fewer bugs&stories assigned - contact us via Intercom and we would be glad to set it up together 🤗
When the feature is ready set all stories and bugs as Done ⌛
Expected result: when the feature is ready set all stories and bugs as Done (sorry, just failed to find other words not similar to the name)
Rule:
When Sprint is finished, move all undone Stories to the next sprint
Find next iteration
Assign all open bugs to it
Assign all open stories to it
Sprints.Filter((Dates.Start() > Today()) and ([Step 1 Sprint].Dates.End() < Dates.Start())).Sort(Dates.Start(), false).First()
Document template for Bugs
Expected result: when a new Bug appears, the default description is loaded to reduce the cognitive load when raising bugs
Rule:
📃 **Steps to reproduce**
Insert link to page and screen size e.g. desktop
👀 **Current result / situation**
Replace with text / image that describes the current situation
👌 **Expected result**
Replace with explanation, that shows how it should beResult:
For this rule & simple, but so helpful example, we need to thank our community champions 💖
If you have other cases in mind, feel free to contact us via Intercom - would be glad to help and improve our articles! 💪