Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VLJ Support: Task auto-distribution discrepancy #14084

Closed
1 task
araposo-tistatech opened this issue Apr 24, 2020 · 11 comments
Closed
1 task

VLJ Support: Task auto-distribution discrepancy #14084

araposo-tistatech opened this issue Apr 24, 2020 · 11 comments
Labels
Feature: generic-queue Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue release-notes This ticket should get release notes generated on merge Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Type: Bug Type: Investigation

Comments

@araposo-tistatech
Copy link

User or job story

VLJ Support's task assignments are distributed in a round robin fashion to ensure tasks are evenly distributed among the team. There appears to be an issue with the distribution logic as the tasks are not being evenly distributed at this time.

Acceptance criteria

  • VLJ Support tasks are distributed equally among the team

Background/context

Issue was flagged by the Deputy Branch Chief Veteran Law Judge Support Branch

Technical notes

Investigation: https://hackmd.io/@hschallh/rJyoSPJYL

@araposo-tistatech araposo-tistatech added Product: caseflow-queue Type: Bug Team: Echo 🐬 Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. labels Apr 24, 2020
@hschallhorn hschallhorn added Type: Investigation Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Feature: generic-queue labels Apr 30, 2020
@ajspotts
Copy link
Contributor

what is this chart?

1 | 
2 | |
3 | |||||||
5 | ||||
8 | 

Why 2?

  • Investigation optimism

Why 3?

  • Time for investigation (same reasons as 5)

Why 5?

  • Investigation uncertainty
  • Commit to the time to make sure we fix the problem

@lomky
Copy link
Contributor

lomky commented May 12, 2020

Investigation complete

  • The very low number of tasksonly shows up for Admin users, who are assigned manually. These results can be disregarded as the auto-distribution applies to non-admin members of the team
  • The bug is traced back to how we re-architectued putting tasks on timed holds.
    • The VLJ Support round robin is based off of the generic Task class, as we want to account for both ColocatedTasks and MailTasks assigned to the team.
    • However, when we migrated timed holds from being on a task to being their own task type, they also appear if you query Task without any extra checks
    • Fix: confirm that our query analyzing who was most recently assigned a task to pick thte next person does not consider 'user invisible' tasks, such as TimedHoldTasks

@lomky
Copy link
Contributor

lomky commented May 12, 2020

The other consumer of the RoundRobin logic is BvaDispatch, however they explicitly look for BvaDispatchTask and are thus unaffected by this bug

@lomky lomky added the release-notes This ticket should get release notes generated on merge label May 12, 2020
va-bot pushed a commit that referenced this issue May 12, 2020
Connects #14084 

### Description
The introduction of TimedHoldTasks introduced a hidden bug in Round Robin Distributions that assumed any type of Task was valid for consideration. When users placed a case assigned to them on hold, it bumped to round robin to them. 

This PR addresses this issue by asserting that Round Robin logic should only consider user-visible Tasks.

### Acceptance Criteria
- [x] Tests pass
- [x] Running RoundRobin cycles correctly through the users

### Testing Plan
Helper Function; set on console:
```
def assign_round_robins(round_robin_distributor)
    tasks = []
    8.times do |appeal|
       appeal = FactoryBot.create(:appeal, :with_post_intake_tasks)
       task = Task.create!(appeal: appeal, parent: appeal.root_task, assigned_to: round_robin_distributor.next_assignee, status: "assigned", type: "ColocatedTask", assigned_by: User.last)
    tasks.push(task)
    end
    return tasks.pluck(:assigned_to_id)
end
```
On master:
1. Create an assignee pool of users
  ` assignee_pool = User.first(4)`
1. Create round robin distributor with type Task and the assignee pool.
  `round_robin_distributor = RoundRobinTaskDistributor.new(assignee_pool: assignee_pool, task_class: Task)`
    1. Run through several assignments, confirm RoundRobin behavior looping through the list of assignees
    `assign_round_robins(round_robin_distributor)`
        - [x] RoundRobin loops through the users
         - note the last user id!
    1. assigned a TimedHoldTask to one of the assignee users out-of-flow (i.e.; if the last user is 1, assign to 3)
    `TimedHoldTask.create!(appeal: Appeal.first, parent: Appeal.first.root_task, assigned_to: User.find( OUTOFORDERID ), status: "assigned", assigned_by: User.last, days_on_hold: 15)`
    1. run the RoundRobin again, confirm the bug and see we jumped out of the RoundRobin flow and assigned based on the TimedHoldTask assignee
    `assign_round_robins(round_robin_distributor)`
        - [x] RoundRobin assigns to the user following the TimedHoldTask assignee, not next RoundRobin assignment

On PR:
1. create assignee pool
  ` assignee_pool = User.first(4)`
1. create round robin distributor with type Task.
  `round_robin_distributor = RoundRobinTaskDistributor.new(assignee_pool: assignee_pool, task_class: Task)`
    1. run through several assignemnts, confirm RoundRobin behavior
    `assign_round_robins(round_robin_distributor)`
        - [x] RoundRobin loops through the users
        - Note the last user id!
    1. assigned a THT to a user out-of-flow (i.e.; if the last user is 1, assign to 3)
    `TimedHoldTask.create!(appeal: Appeal.first, parent: Appeal.first.root_task, assigned_to: User.find( OUTOFORDERID ), status: "assigned", assigned_by: User.last, days_on_hold: 15)`
    1. run the RoundRobin again 
    `assign_round_robins(round_robin_distributor)`
      - [x] confirm continuation of previous RoundRobin flow, not a jump to the user following TimedHoldTask user

### User Facing Changes
None

### Code Documentation Updates
- [ ]  Add note to [Auto Task Distribution](https://github.com/department-of-veterans-affairs/caseflow/wiki/Automatic-Task-Distribution#vlj-support-round-robin)
@lomky
Copy link
Contributor

lomky commented May 12, 2020

@araposo-tistatech The fix for this is merged and will go out tomorrow!

I suggest we keep this issue open for another week or two and keep an eye on tasks assigned moving forward to watch for any other potential issues.

@araposo-tistatech
Copy link
Author

@lomky unfortunately, the VLJ Support team has reported that this issue has not been resolved. Please see their findings below:

"It appears that the work distribution issue for VLJ Support has not been resolved. Please see below chart which shows the amount of work assigned to each employee during the period of May 9 through May 16, 2020. I pulled this information from Tableau because we are not able to get a clear/accurate number from the VLJ Work Queue. I am hopeful that your team will be able to correct this issue to ensure that work is being distributed evenly. Any assistance you can provide with getting this corrected is much appreciated. Please note that Tirza Austin-Jenkins departed the Board on May 8th and she was given admin rights at the end of April so that she would not receive any additional work that she couldn’t complete.

Employee Name Legacy Tableau View AMA Tableau View  
Bergeron, Ronald 49 17  
Clanton, Lazette 42 24  
Crews, Tashauna 25 8  
Drayton, Maleka 49 14  
Jenkins, Michael 9 2  
Johnson, Andre 39 12  
Jones, Maurice 33 9  
Koroma, Marvin 26 13  
Lewis, Lofrandra 42 8  
Maiden, Linda 28 11  
Marshall, Patrice 40 3  
Moss, Andrea 30 9  
Seay, Randy 31 9  
Totten-Browning, Pam 38 9  
Wiggins, Gwen 37 7  
Tirza-Austin-Jenkins 3 0  
Totals 512 153 665
"

I realize it is probably very unlikely, but is it possible that the data in Tableau could be off?

@yoomlam
Copy link
Contributor

yoomlam commented May 18, 2020

@araposo-tistatech My 2 cents: I wouldn't expect the numbers to even out immediately since cases that have already been assigned (before the fix) will stay with the current assignee.

@araposo-tistatech
Copy link
Author

@yoomlam appreciate the input! I've gone back to VLJ Support with your note and will await feedback.

@hschallhorn
Copy link
Contributor

Please note that Tirza Austin-Jenkins departed the Board on May 8th and she was given admin rights at the end of April so that she would not receive any additional work that she couldn’t complete.

We should direct them to make this user inactive in caseflow rather than making them an admin. This will ensure they are not assigned any more tasks, but the correct way

@lomky
Copy link
Contributor

lomky commented May 19, 2020

@araposo-tistatech The round robin is now working as intended.

Over the last 6 days 287 VLJ Support Tasks have been assigned. They have gone out evenly at approx ~20 tasks per user. There is one user with 4, but as of last week that person was marked as an Admin, and it looks like they were only added back into the round robin today.

If they need us to adjust anything retroactively, we can, but we'd need their guidance on how to go about that to avoid interrupting anyone's work.

# Gather all the Tasks assigned the VLJ Support in the past 6 days
> org_tasks = Task.where(assigned_to: Colocated.singleton, created_at: 6.days.ago..Time.zone.now)
# Gather all the individual user tasks assigned to members of VLJ Support under those Org Tasks
>  tasks = ColocatedTask.where(parent: org_tasks, assigned_to_type: User.name, created_at: 6.days.ago..Time.zone.now) 
# How many tasks?
> tasks.count         
=> 287
# Assigned to whom?
> counts = tasks.group(:assigned_to_id).order(:count).count
=> {2062=>4, 2012=>19, 2014=>19, 1967=>20, 10630=>20, 1782=>20, 1885=>20, 2227=>20, 6169=>20, 1379=>20, 7798=>21, 10627=>21, 1829=>21, 2101=>21, 2141=>21}
# Map to names
>  pp counts.map { |user_id, count| [User.find(user_id).full_name, count] }
=> [["MICHAEL JENKINS", 4],
 ["MAURICE JONES", 19],
 ["LAZETTE CLANTON", 19],
 ["RANDY SEAY", 20],
 ["TASHAUNA CREWS", 20],
 ["LINDA MAIDEN", 20],
 ["ANDRE JOHNSON", 20],
 ["MALEKA DRAYTON", 20],
 ["RONALD BERGERON", 20],
 ["PAMELA TOTTENBROWNING", 20],
 ["GWEN WIGGINS", 21],
 ["PATRICE MARSHALL", 21],
 ["LOFRANDRA LEWIS", 21],
 ["ANDREA MOSS", 21],
 ["MARVIN KOROMA", 21]]

# why does M Jenkins only have 4? 
# They were marked as a VLJ Support Admin as of last week, and admins don't get autoassigned.
# so their number is different because they were previously not in the round robin

@araposo-tistatech
Copy link
Author

Maria from the VLJ support team got back to us stating two users (Lazette Clanton & Ronald Bergeron) are still receiving more tasks then other users. Below is the report she provided (May 25th - June 3rd):

Legacy Task Table
AMA Task Table

Based on the previous note Kat provided it does appear the tasks are being distributed evenly. Can we pull an updated report to ensure nothing has changed? I suspect the discrepancy is some users are completing their tasks faster than others, but I would like to present some data when I respond.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature: generic-queue Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue release-notes This ticket should get release notes generated on merge Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Type: Bug Type: Investigation
Projects
None yet
Development

No branches or pull requests

6 participants