Feature/Epic level task status

Situation:

As a Project manager, Product Owner, or Development Director often would like to see the overall status of the feature/epic level tasks, without dwelling on minor details and checking each subtask/user story for information.

It takes time to go through each task and check their status trying to understand if the feature/epic is in progress or still not started.

Wanted actions and how it saves time:

Each feature/epic should be connected with its subtasks/user stories and be actively updating depending on what is the status and position of the subtasks/user stories in the current sprint or project.

This would allow to have a separate board with only feature/epic level of tasks for management to present or have an overview of the current situation and estimations.

Solution:

Using the combined actions of ''When all cards are in status'' and ''Change status of other cards'' you can set your feature/epic tasks synced with your current subtask/user story statuses from your sprint board to the backlog.

Using the same setup it can also be made to update a specific card using the ''Change status of other cards'' automation:

All cards - all cards on the board

Parent card - only parent cards that are related to the subtasks/user stories

Select card - a specific card of your choice


Release/Milestone Tagging

Situation and why it takes time:

A Program Manager, Product Owner, Development Director, or Producer needs to tag features (user stories) to a specific release and/or milestone.

It is time consuming for them to manually add the cards to both the release/milestone board and to the release/milestone burndown board.

Wanted actions and how it saves time:

True release/milestone tagging and tracking is achieved by simply tagging features (user stories) in a product backlog and having those cards automatically added to the corresponding release/milestone boards & columns.

Solution:

Using the action "When any field changes" and adding tags, the card will Add to board in the required status.


User Story QA Reviews

Situations and why it takes time:

Embedded QA Analysts on a Scrum team, especially on remote and distributed teams, need to know when a user story is ready for them to review in order to quickly discover Sprint found bugs and provide fast feedback to the rest of the development team. This is time consuming and is often missed slowing down the entire development process because the developers must manually notify the QA Analyst that the user story is ready for their review and manually add the card to the QA review board.

Wanted actions and how it saves time:

When any user story is ready for review the embedded QA Analyst should be automatically assigned, notified, and have the card automatically appear on their review board. Also, once approved the user story should automatically move to Ready for Product Owner Review on the Scrum team's board. This minimizes the QA review bottleneck and speeds the resolution of found bugs, team feedback and time to delivery.

Solution:

The solution automation is that the embedded QA Analyst is automatically assigned, notified, and the card is automatically added to their own review board.

Automations Screenshots:

Scrum Team Board:

QA Review Board:


Team Member Utilization Allocations & Tracking

Situations and why it takes time:

Program Managers, Scrum Masters, Development Directors, and Producers need to know both current and future allocations for all team members, often across multiple scrum teams. They also need to track discipline specific capacity vs. planned scope. This is currently a very manual process and difficult to visualize in Favro without time consuming manual tracking, assigning, and user story movement / addition across multiple boards.

Wanted actions and how it saves time:

When a user story or task is moved from unassigned or to any team member's column on a Capacity Planning board, the corresponding individual should be assigned always showing an accurate reflection of how much work is currently assigned to each team member across each discipline.

Solution:

When a card changes status, the automation will unassign and assign members based on the work allocation of each member.

Did this answer your question?