+8
Qualified

Ability to reassign "Assigned" tasks on Agile Board.

Michael Scott 4 months ago in Productivity Management updated 5 days ago 19 1 duplicate

It would be great if you could reassign "Assigned" tasks directly from the Agile Board.   We can already reassign "In Process" as well as "Projected" tasks when you click on the Task Tile, but for some reason cannot reassign, assigned tasks.  This inconsistency in functionality requires the Project Manager to go into the Task List or Worksheet and reassign the assigned tasks from there for those situations.   

Duplicates 1

Thanks for the quick feedback.  So just to clear we are saying that the "at least 1 reviewer" can be someone who has already voted right?

Example 1:

3 people are on the review.  1 person has voted.  Other 2 have not.

When I open the modal pop up window, the person who has voted should be listed in a separate section or disabled and I can see if they approved or rejected.


The other 2 reviewers would be in the assigned field I should be able to remove both of them and NOT add anyone new (since there is 1 reviewer that already voted) and save it.  Doing that would cause the review to end and the outcome would be decided by however the 1 reviewer had voted.

Example 2:

Same review with 3 reviewers but in this case NO ONE has voted yet.  In this case, I open the modal and all 3 are available to be removed but if I try to remove ALL 3 the system would not allow me to save and would prompt saying that at least one reviewer must be assigned.

Agreed?

Agree with that logic

Yes, agreed that "at least 1 reviewer" can be one that has already voted.

We have been on the fence about rolling out the Agile Board because of this issue.  While we see a great benefit to roll this out, we don't want only half our users to have this and the ability to reassign via the Reassign Tasks module. It is the Contributor users that don't have any ability to reassign tasks and they have a great need to.

We'd like to see the following:

  • Do not remove reviewers already voted, we'd need that information retained
  • Would like to see voting style, this would be helpful to know 
  • There should be at least 1 reviewer left; this is about "reassigning" reviewers not removing the review task

Also for expectation setting, I agree this is something we want to support with the right guard rails. Given our current roadmap and commitments I do not see this being something we can slot until 1H 2021.  Likely could start work in Q1 and release sometime afterwards once we understand scope.

So we would not allow you to remove reviewers that have already voted.  I agree that make sense.  Beyond that any other restrictions?  Does the voting type matter in this case?  Do we need to show that information to the user on that pop up window?  I think it might be useful because the voting style will impact how the outcome is calculated.  Would most users know the differences in the types?  If so show "all must vote or majority or a single approval, etc?

Also, we would immediately then recalc the results which could immediately cause the review to close.  I assume that is what everyone would expect right?  


last, if no one has voted, then everyone would be "available" to remove.  So should we allow everyone to be removed or should we require at least one reviewer is selected?  I would think we would want to enforce at least one reviewer is still on the review but open to others opinions.

Agreed : 
- recalculation can indeed close the review immediately (intended behavior)
- yes, a minimum of one reviewer should be obligatory (in worst case the user, can re-assign to himself)
- The voting style is not a must, but can be informative. 

I agree with these from our perspective as well.


I agree with Bart's recommendation.  It would be important to retain those that already voted (and see what their vote was) and allow them not to be reassigned, while having the ability to reassign any reviewer that has not voted (whether in the Assigned, In Process or even has Accepted status).

That should work.

In Review

Hi All,

I am apologize for not updating this earlier.  It seems to have slipped through our process.  This Idea is very similar to this one.

https://voice.aprimo.com/communities/42/topics/2139-ability-to-reassign-assigned-tasks-on-agile-board

Please see my updates on this one and if you agree I will merge these together?

Thanks,
Eric

Hi Eric - I feel these two can be merged and I posted a reply to the other ticket as well.

We have not received approval from Aprimo for our request as of yet.

Hi Ken - I was looking for an update from Aprimo as I didn't see one on the request.  Thanks, Christine

As we are thinking about rolling out the Agile Board to our users, one of the main reasons for this would be to allow our Contributor users the ability to reassign tasks.  It looks like the current functionality does not allow for tasks that are in the Assigned status (which does not make any sense as it has not been accepted yet), but we would also need for the ability to reassign any tasks that were in the Assigned and/or In Process status.

Can you please provide some update on this?

Hi,

We had a similar request for one of our clients a while ago. Basically, they actually were interested in the use case described above by Eric: the 'all must vote" case that immediately ends a review. A proposed campaign asset is there typically presented to a broad number of reviewers (with different expertises) to collect their feedback before sending it out for print production. All reviewers are asked to vote (ok vs. corrections needed). But in some cases the workflow is stalled, because one of these voters doesn't respond fast enough, is absent or simply doesn't care. In that case, the workflow requester (typically a contributor user who started the project in the first place through work request) would like to use the agile board and remove that blocking reviewer from the task and have the workflow proceed. Mind, in that use case, we would still need a way to see for each of the reviewers, whether a vote was already casted or not. It makes indeed no sense to remove an assignee from a task that was already done by that person. Would it be an possible to gray out these persons on the popup?

In Review

Hi Michael,

You are correct that is currently a limitation.  The reason for it is because a Review Task always stays in "Assigned" status and does not move to "In Process".  If you open a review task, you do not want to remove/reassign someone who has already voted on the task.  When we added the simple modal on the Agile Board it does not work well to show that detail and manage those restrictions.  Supporting this would require updating that modal for Review Tasks to show all the reviews individually and their current voting status and only allow changes for those that have not voted yet.

Also, removing reviewers can immediately change the outcome of the review.  If you have an "all must vote" setting and 2 have voted and one has not and your remove them then the review immediately ends, etc which may not be as intuitive to understand as a user on the modal window right now.

Is your use case for changing assignment of Review Tasks or regular tasks that are just still only assigned and not accepted yet?  We can look at allowing it for regular tasks as that has less impact.

Thanks,
Eric

Hi Eric, 

From our case, it was for the Review Tasks and I can certainly understand that challenge described.    Our configuration is a combination of first vote decides and consensus, so we could see both scenarios.   It could be that we are earlier with our implementation across various groups in our organization, but users seem to sometimes assign tasks incorrectly to the wrong people and they are looking for ways to intuitively and consistently reassign.   A lot of people like the Agile board view and features so was just an idea for exploration of feasibility.

Qualified

Sure, makes perfect sense and it is a use case we want to support at some point but it would require modifications to the modal window and more validation to account for the use cases above which was why we put the initial restriction on it that we have right now.