Cloning OKRs to a new quarter

This page highlights what problem are we trying to solve and the solutions for the same

Before we go into the solution, we would like to scope the problem and discuss elements/use-cases of the problem are we trying to solve and what elements/use-cases we won't be solving

What we aren't solving? - Drafting of similar goals Same goal title with revised targets (end/beginning of quarter)

No, because tool doesn't add much value in this case. As good as creating a new one and KR's also have be newly defined. The progress also will start fresh and hence the terminal states when carried forward will have to be changed. Having said that, our users can still use the functionality to do the above. It's just that we aren't optimising for this use-case.

What we will be solving? - Spill/roll-over of OKR's Goals which didn't get completed and would be continued in the next quarter

The tool adds a lot of value in the above cases as one doesn't have to re-write the entire cascade tree and also retains all the activity on these OKRs and can be worked upon in the next quarter in continuum.

What all can happen to an objective which is worked upon in future quarters as well?

Theoretically, an objective that is moved can have a few KR's which have to continue, a few which are no more relevant and a few KR's which are added new. Thus, we can expect that changes to relationship is a very common occurrence and hence we arrived at a solution of "Cloning this OKR" in a new timeframe.

Solution

• A user sees an option of "copy to: quarter" in the 3 dots menu of an OKR

• A user then gets a modal where they are given a choice of

  • which quarter do they want to copy this objective to

  • and also whether they want to only

    • copy this objective or

    • Copy this objective with its KR's

    • copy the entire tree (everything below it) Both the 2&3rd options will have a sub-option to select "Exclude achieved objectives". Note: If there are any non-achieved KR's under an achieved OKR in the tree. Then those do not get copied.

Open points:

• We then show a toast that we are copying the relevant items to next quarter?? [Need to think of a loading state/ background state]

• Do we show the toast only after its done with a view CTA? If yes, then just after action how will user know what's happening? If we show loader, then user cannot do any other action. What if the time here is very high? (Refer to design for the above exp)

• Once the action happens, the user gets a view toast and can see this objective in the next quarter.

Note: While cloning, we take the latest snapshot of that OKR (title,owner, teams, status/ progress etc) but the due-date is now shifted to the end of new quarter. However, any change to this OKR unit now onwards only reflects in that relevant quarter to that copy.

Note: Accept/Reject flow gets triggered for all. Note, that the check of accept/reject now is on copier & owner rather than assignor/creator & owner.

What happens when someone goes back and edits this OKR in the previous quarter?

We will give a toast/info bar to the user if they are making changes to an objective which was copied to a future quarter. (Suggesting stale view)

This toast will be actionable with two option: Cancel and proceed We would honour if a user still wants to make changes to this OKR and it will update the time on this OKR card without affecting anything on the new OKR clone that exist in another quarter.

Few more clarifications:

• Do we give the option to the user to reset the status/progress and use same tree with revised targets next quarter?

As mentioned above, this is the case we won't be solving. What if people don't revise targets properly and then sandbagging happens. Having the trail is always better.

• Where all does this OKR now show up?

This objective should show up in all relevant tabs - My objectives, team objectives and all objectives

• How does it show up in "All objectives" if its root parent is not copied? (If root parent copied (C/NA), then no issue as we show that with quarter label)

An objective which is copied to a new quarter without the parent being copied would now be treated as a Non-aligned root OKR. There wouldn't be a show alignment button on this objective. [the user can see the context from the activity feed]

• Can this objective now be linked to some other objective higher up?

Yes, the move and paste should work and give the desired outcome.

• What are the changes to the permission matrix? Should we allow the complete tree access?

Yes, permission matrix would change to Parent chain owners having permissions to do actions. (Eg: Move, Copy and Delete entire trees)

Activity feed info

Note: The activity feed for both the copies will be different with a link to each other Check design for this

If someone copies the entire tree, then activity feed of all OKRs should reflect this activity.

Notifications

For now, there would be no email notification on this. However, we would trigger an in-app notification for all KR's being moved.