Feature Handoff Checklist

Work long enough and your organization will change. Your organization grows and builds and new teams spring up to handle the work. Priorities shift and what you are working on needs to happen elsewhere. Your team now owns something new to them.

I wrote a checklist on how to handle features or products moving from one team to another. Maybe it will help you the next time you go through team responsibility changes.

What is this checklist?

A guide to feature handoffs. A feature handoff is when one team needs to take ownership of a feature, product, and/or service, from another team.

For example, say Team Y forms and now they are responsible for Features A, B and C that Team X originally built. How should Team Y ramp up on Team X's features?

Or, imagine that Team Z needs help completing Feature D in crunch time. How might Team Y collaborate and help Team Z?

This checklist helps you think through the timeline and plans.

Note: I use the term receiving team to describe the team getting a new feature. Original team describes the team transferring the work.

Checklist

1. Who is the Directly Responsible Individual (DRI)?

   1. Identify the DRI from the receiving team. This person owns the handoff process and is responsible for a smooth transition. (Or as smooth as possible.) For example, the DRI should:
      1. Schedule kickoff or transfer meetings
      2. Make a decision on who needs to be involved going forward. For example, are you borrowing Team Y and want them to attend meetings on Team Z? The DRI is responsible for making sure that happens.

2. What is the timeline?

   1. When will the receiving team own the feature? When will the receiving team need to start and complete the work?
   2. Are there existing customer commitments / service level agreements (SLAs) with deadlines?
   3. Is there enough time to complete the transfer? Once you decide to transfer a feature or move people around, there should be at least 24 hours for Engineering or Product Managers to inform the receiving team that priorities are changing.

3. Schedule a 1 hour Product focused handoff meeting. This meeting is costly for a reason - handing off a feature involves a lot of context. If a handoff is necessary the receiving team needs support.

   1. The DRI should set up a handoff meeting with the following:
      1. Product Managers (receiving and original team)
      2. Designers (receiving and original team)
      3. DRIs and engineers from the _ original team_ that designed or built the feature
      4. DRIs and engineers from the receiving team
   2. The meeting should cover the following:
      1. Background of Why this is a feature/need
      2. An high level product and feature overview
      3. Product Requirement Documents (PRDs), Architectural Decision Records (ADRs) and other documentation
      4. Existing commitments or SLAs
      5. Known issues, major bugs, or items left incomplete
      6. Future Roadmap

4. Schedule a 1 hour engineering focused follow up meeting. After covering the features at the product level, leave time for the team to investigate and think. The second meeting is a chance to dig deeper and look at code, metrics/dashboards, backlogs, etc.

   1. This meeting should involve:
      1. DRIs and engineers from the original team
      2. DRIs and engineers from the receiving team
      3. Optional: Product Owners, Designers, Support Team
   2. This meeting should cover:
      1. Where are the runbooks and documentation?
      2. How do we observe the system? What monitors or alerts exist and where are they?
      3. Where are the current major bugs or known issues?
      4. What have we knowingly skipped (i.e. we don’t support ____ for this feature)?

5. Do all parties understand the receiving teams’ processes and meetings?

   1. How does the original team help in the future? What involvement will be required in the short and long term?
   2. Optional: Invite relevant parties (Director of Engineering, Product Managers, etc) to the receiving teams stand ups and planning meetings?

6. Will this feature return to the original team? Is this a temporary transition (i.e. Team Y lends 2 members to Team Z for 2 months)?

   1. If yes, identify the DRI of the original team who will handle the transfer. Repeat this checklist.

Comments

[John P. Rouillard]

Nice list. Sadly we often get:

• Where are the runbooks and documentation?

What's a runbook and where's Steve.

• How do we observe the system?

Telnet to here. If it doesn't prompt you it's down.

• What monitors or alerts exist and where are they?

This was Kevin's job before he left.

• Where are the current major bugs or known issues?

It's here: Logs into jira, pulls up a search, 2127 issues returned.

• What have we knowingly skipped (i.e. we don’t support ____ for this feature)?

Staying up for more than 8 hours (no I'm not kidding).

[Andy]

Thanks John. I see you’ve been around the block on these before haha.

As a “receiving team” member a few times I learned how valuable it is when the original creator sticks around and can walk you through the system. But that doesn’t always happen…

[John P. Rouillard]

Yeah, had a 3 week period where an important feature server seemed to go down every 8-12 hours. On call the first week it was live was miserable. After that we had our Twiki run books and automated restarts tied to Nagios.