Feature Handoff Checklist
Tags: productmanagement, softwaredev, engineeringorganization, checklists
Published: 2022-11-21 18:39:52

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
      2. Product Requirement Documents (PRDs), Architectural Decision Records (ADRs) and other documentation
      3. Existing commitments or SLAs
      4. Known issues, major bugs, or items left incomplete
      5. 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.