Sprint 0 in Knowledge Transfer Project

I have been working for GFT for 4 years. During this time, I have had the opportunity to work on 4 different customer projects. Starting a new project is always a great experience but also brings a lot of challenges. Fortunately, in GFT we have a process called “Sprint 0” that helps Project Heads to organize co-operation with client and team’s work. Today I wanted to share with you a quick overview on how to implement Sprint 0 in Knowledge Transfer Project. It is based on my latest project.

Knowledge Transfer Project

It often happens that the development of the application lasts many years. During that time the companies are being bought and sold, the agreements signed and expired, people starting and finishing the work. That is why handover process is an important part of development. Our adventure starts with our customer selling the part of their group (this included teams supporting and developing main applications). Since after the sale these teams would no longer support or develop or maintain and deliver new functionalities, GFT was asked to help gather the knowledge and support the future delivery.

Summing up the Knowledge Transfer Project is the name for the project for which development and maintenance needs to be handed over to different team or company. The main goal for the first phase of this kind of assignments is to gather technical documentation and knowledge on already existing software so that it will be possible for a new team/company to continue the work.

Sprint 0

Working in GFT is all about taking care and providing the technical support for our clients. We do pay a lot of attention to help our customers get through difficult processes such as creating new solutions by starting new projects, migrating applications to new infrastructure e.g. cloud but also transferring existing solutions for new development teams. We strongly believe that being honest, transparent, and setting up clear rules with our clients will help us build a relationship needed to provide high quality service. Therefore, we have created a process called “Sprint 0” (it is described as part of Agile DevOps handbook) to ease our Project Heads/ Project Managers with starting co-operation with new projects/clients. It covers all of the areas: roles and responsibilities, tools (access rights) and scope (backlog of things to be done). In the next chapters you will find the details of this process and how I accommodated this process to Knowledge Transfer project. See the typical Sprint 0 agenda on screen below.

Roles and Responsibilities

At the beginning of a new project (especially when starting with a new client) you will need to agree on roles and responsibilities. It is always the best to have an honest conversation between all the interested parties. How to prepare to this meeting? Before setting up an appointment make sure you understand the goals and restrictions of the project e.g. if it is maintenance only or maintenance and development project, if this is internal applications or used by external clients, what downtime for application is allowed, what kind of support is needed. It is good to organize the first meeting just to get to know all the parties that will take part in the process. It is good to prepare list of base responsibilities and list of all parties, these can then be used to create a RACI table. Remember to always send minutes from the meeting so everyone may confirm all things noted down are correct and agreed with them.

How I did it in our project?

Firstly, I met with our main contact on client side so that I could get the overview of the goal and the parties interested in the project delivery. Then, we planned meetings with the client teams we were going to start co-operation with. These were the Business and Product owners and  L1/L2 support line (24/7 support teams for the websites we needed to take over). During these meetings we made a list of agreements regarding ownership and responsibilities for each team member – as a result RACI table was prepared by Javier Saez (GFT Project Manager). You can read more about what is RACI here. Remember a RACI requires to be checked at least once a year during the project delivery – just to make sure it is covering for all the changes e.g. teams structures, project scope.

Tools/access rights

Secondly, you need to cover for access rights and tools that are required to do Knowledge Transfer and in the next project phases while continuing work on development. It is good to get knowledge on how we are going to work, what is necessary, what are the processes to onboard team members, who will be your contact for these topics from client side. Remember this is the first time you can review tools used by the client so far and propose changes or introducing new, additional tools. Fortunately, not the last one.

How I did it in our project?

For this purpose I organized a number of sessions between old development teams we were taking over from and GFT developers to go through all the tools they were using and GFT Teams needed access to. I created a checklist with the systems/applications needed and during next sessions the GFT team started to fill it with the details on how to request listed permissions. See the example of checklist on image below.

Scope (backlog and roadmap)

Since we already know our responsibilities and tools we are going to use, we are able to focus on scope of our work, and the best time to agree with the client of what and when is expected. And as you probably now already understood, yet again it is all about meeting and talking through the project details and then documenting all agreements.

How I did it in our project?

The KT (Knowledge Transfer) project is quite specific as the first part of backlog will all be about getting the knowledge from the previous team. The best approach is to start with Architect/Tech Lead to meet with the existing team and prepare the list of applications and modules. Next step will be to create the architecture diagram to understand all the dependencies and integrations. It may also help fill in the parts that were omitted when discussed for the first time.


As we already know goals, we need focus on how we are going to track and report progress toward the goals. As the part of this process, it is needed to agree on milestones and deadlines. Remember it is not only important for the communication with the client but also for the team to be able to better organize their work and raise any issues and concerns with the timelines ASAP.

How I did it in our project?

I decided to prepare Knowledge Transfer Plans. For each website/project in scope I prepared High and Low-Level KT Plans. Both were presented to the client and then reviewed on weekly basis. The details and differences between those are presented in the table below.

Do not forget about assumptions – it is important to state what needs to be provided to team so they can deliver in given deadlines. See the example of High Level KT Plan on screens below.


Unfortunately, no matter how good the plan is, not everything will go according to it and issues are expected to occur. Do not panic, as long as you communicate them to the client, and all parties together doing their best to sort them out – you can still meet given deadlines. It is important to address all issues. There are two steps for this. Firstly, you need to build safe environments for the team to report them to you. The way you react to raised issues will reflect on those being reported or not. Never blame the person who delivered bad news, focus on being helpful and finding a solution together. Sometimes you may need to include other members of new team, Client or old team – this is ok as long as everyone is focused on solving issue. Secondly, you need a way to report and track those, a RAID is a good tool to use for this

How I did it in our project?

I started working on team atmosphere on the first day we met as the team. I organized a team meeting, so that we could meet each other but also agree on the co-operation rules. I stated what my expectations were, but also listened to what team wanted to say and add. It is important that all team members feel they had a chance to be a part of these agreements. We placed all rules on Confluence (you may use any other tool that will allow everyone to revisit and edit when you decide to add/change rules later). Then, of course, I created a RAID – it allowed me to track issues but also to provide full transparency against KT process challenges. Together with the client and teams we decided this should include such information as:

  • Affected team
  • Type (Risk, Issue)
  • Priority (Low, Medium, High, Blocker)
  • Title
  • Description
  • Mitigation
  • Affected users
  • Status
  • Status comment
  • Date raised
  • Date closed
  • Owner

SCRUM Process

Last, but not least you need to take care of how you are going to organize work. Firstly, it is good to get to know current processes. Secondly, it will be good to review them with the team and client to agree if they meet their needs. Remember not all team/client requests will be satisfied in new processes – you might need to find a middle ground between team/client needs and what may be done/changed in given timelines.

How I did it in our project?

Yes, you guessed – it was yet another meeting and discussing! The team and I got to know the existing processes, reviewed it with the current team and client and decided to do changes in three stages: Existing process, Processes during KT, Processes after KT finished. We summarized in a table and published it. You can see example below.

Sum up

The KT Process for my teams ended on 1st April 2021. Since then, we have migrated the remaining parts of the maintained websites to AWS as part of the Separation Programme and the team continue with the development and support. More details on the project and team successes in next post so stay tuned!