Category: PM Team Space

1. Open https://cheitgroup.timedoctor.com/ in your browser

2. Click on the left menu expand arrow near your name

3. Click “Your integrations“ and follow the instructions which described in the Jira Software section

   

4. Go to the https://id.atlassian.com/manage-profile/security/api-tokens

5. Click “Create API token“ button

   

6. Name it “Timedoctor“ and click “Create“

   

7. Copy new API token

   

8. Go to “Your Integrations“ page in TD https://cheitgroup.timedoctor.com/v2/index.php?page=integration_settings

9. Paste the API token and enter your Jira email address

   

10. Turn on “Jira integration”

In case of any questions, please contact sophiabilyk

Time Doctor / Jira integration

• Integrate Time Doctor with Jira using following instructions https://cheitgroup.atlassian.net/l/cp/RK7J0pns

• PM must make sure all devs, QA from your teams completed the integration and using TD tracking in Jira and give integration instructions for new people in the team

• During Issue goes through the Workflow, it should be assigned to the specific person and set with current status before start tracking

• In some specific cases, time from the issue could be edited manually in the TD – Edit time

Planning & Reporting

• Each project should be divided by Sprints (exception is some unstable Support projects)

• Planning meeting should take place at the beginning of each Sprint

• Each Sprint should also contain at least 3 Communication tasks (if needed for each team member separately as sub-tasks): Communication with the Client, Daily Meetings, Tasks Discussions / Communication with the team AND all time should be tracked by each team member in these Issues

• Tasks for QA in some cases could be created separately, but MUST be included to the Sprint

• PM can start Sprint when all above steps are completed

• All additional issues could be added to the Sprint ONLY by PM

• PM’s responsibility is to check each Issue progress, time spent and control the Project’s budget; dev/QA MUST communicate all risks related to the “In Progress” Issue, including over-budgeting on Daily meetings
  *For easier monitoring, we are working on the Reports system – will be presented soon

• PM should communicate all risks to the Client ASAP

Tracking rules for the team

• The whole time spent on the Project should be added to the Project

• All tasks should be added to Jira and tracked through the TD/Jira integration, avoiding manual creation of the tasks by dev/QA
  Please notice that project in TD would be created automatically and named JIRA: Name_of_Project

• The whole dev, QA, PM work on task MUST be tracked to the specific Jira Issue

• When Dev, QA starts to work on the Issue by getting acquainted with the Issue – it should be tracked to the specific Issue

• If there is no left tasks in the Sprint, dev/QA should communicate it in the Project’s channel; if there is no tasks which could be assigned to the dev/QA PM should notify the #pm channel
  In the meantime dev/QA could track their time in Design&Development (this project is only for internal company tasks)

• Daily meetings must be tracked in “Daily meetings“ task, created for each Sprint by each team member

• Calls / communication in Slack with team regarding tasks must be tracked in the “Tasks Discussions / Communication with the team“, created for each Sprint by each team member

• Copy this template to make your PM Weekly Report – https://cheitgroup.atlassian.net/l/cp/1szAKcP1

• Bring the table structure to the same view for everyone – the order of the columns is as follows: Scope/Projects, Status, Deadline, Budge (Estimated, Spent), Additional Requests (Estimated, Spent), Team, Update

• Use Statuses – ON TRACK, PAUSED, WITH RISK; If it’s support or internal project just add it to the status like that ON TRACK (support)
  Use colors – https://i2.paste.pics/OOE4N.png

• Check the fields Status, Budget, ETA – we often copy reports from the previous week, and change the information in the Update column, forgetting about all the others (also new projects)

• Sort your projects in a table by the number of hours – Current budget (from the top – the largest, from the bottom those that support, pause, etc.)

• Make sure that the formatting of the text helps in the readability of the report (in the Update column, all points are divided by a bullet list, a new line begins with a capital letter, a period or other punctuation at the end of each bullet point is not necessary; all columns are of the required width so that the text is not cut off; if cell is empty put “-“)

• If you are replacing someone on a project, add these projects and their statuses to your report + add this person on “CC” to your email

• Before sending, read your report again, make sure that the details you have wrote comprehensively describe the current situation on the project, without going into unnecessary details

  Pro-tips:

• Remember for whom you are sending reports, and what information this person needs, try to read your report through the eyes of this person (for example, do you need information about every bug on the project – NO , do you need information about problems with the budget or responsiveness developer/client – YES )

• A report on projects for our management != (not equal to) a report for the client, you should pay more attention to the team (if you notice burnout in someone, weak progress, or on the contrary, you should praise someone), you feel that something is not working as it should be in the processes – mention this information in the report, and of course it is important to notice the nuances of the budget/overtime and always keep your finger on the pulse

• If there is a problem, add a note about the steps you plan to take to solve it – show your proactivity

• And finally, remember what Alex/Slava most often ask you about in DMs or at meetings, you definitely need to pay attention to this in the report

 Overview

The QA process in development is an important step to ensure the quality and functionality of a product.
It involves testing and verifying that the product meets the specified requirements and specifications.
This documentation provides an overview of the QA process including PM, QA, Dev responsibilities.

 Preparation for the Project’s start (pre-development stage)

• QA should be assigned to the Project as a dev team by PM, i.m.
  — Added to the Project’s group chat/channel in the Slack
  — Added to the Jira Project
  — Added to Time Doctor
  — Involved in the Estimation phase, QA time should be added to the separate column in the Estimation file

• PM should create Project Passport & Requirements documentation

• PM should discuss with the Client his preferences regards QA Approaches & Supported browsers and devices and pass it to the QA
  (Examples )

• Based on the above information, QA should prepare QA Documentation (Supported browsers and devices, Test Strategy, Test Cases*, Bug Report Instructions) in the Confluence Project’s space
  *Test Cases is a new procedure, which would not be applied to all project just yet

• PM should add all tasks divided by Epics/Stories describing main functionalities of the project
  — All Issue details should be written in English and well described
  — For all Issues, where it’s needed, should be added Acceptance criteria in the “QA Scope” field
  (Examples)

Development + QA stages

• QA should test the whole Epic/Story, when FE+BE is completed (avoid FE or BE testing first – required for the new Projects, which were done from scratch), in the all other cases (Support, CR, specific functionality) – Task/Epic/Story

• After Task/Epic/Story is completed and initially tested by the Dev, Dev (in some cases PM) should assign it for the QA and change status for “Ready for Testing / QA“

• All Bug tasks should be created by the example of this template and linked to the certain Task/Epic/Story

• UAT report should be sent for Client by PM – all requests / bugs from Client should be received in the way described in the UAT doc*
  * UAT template 1 (for Clients added to Jira), UAT template 2 (for gathering feedback from Client in the file)

• After the Bug is fixed, it is tested once more by the Dev, and afterwards sent to QA for Bug verification

• After the testing is successfully done, Task/Epic/Story should be transferred to the “QA Approved“ status by QA

• The Task/Epic/Story could be considered as “Done”, when it’s uploaded to the production by Dev

• For all Issues in status “Done“, the verification on production is a MUST
  QA could use Regression or Smoke testing on production depending on Project needs

General Communication orders:

• Daily meetings w/ team, including QA

• Retrospective after each Sprint, once in 1-2 weeks (depends on project’s needs)

• Priorities of Projects for testing should be communicate each week on the PM meeting / Workload planning or directly in the #pm channel during the week by PM

Before you start planning your Handover, please copy this page to your personal Confluence space and mark all checkboxes before you start vacationing. Add your name/surname and vacation dates to the name of the page.

📋 Initial Communication & Handover Scope preparation

• Send a vacation / day-off request to Hurma

📍 Golden rule: [Date of the request for the vacation / day off] >= [Time of the vacation * 2]
(e.x. You plan vacation for 1 week, then you should notify management team about your vacation at least in 2 weeks before planned vacation date)

📍 Make sure your vacation time do not coincide with any releases

• Prepare the list with all your projects using this template
• Assign responsible PMs to handover your projects

• Discuss w/ management team who can handover your projects (if needed)

• Send the Handover file to #pm (notify & tag responsible PMs)

• Send message/email with notification about your vacation / day-off to your clients (Slack/email)
• Add responsible PM to the chat with client
• Send notifying message to your team members about your vacation / day-off
• Add responsible PM to chats with team members

🔎 Tasks & Projects

• Do preparation work with the customer before you go

• Discuss the scope of work, which should be done during your absence

• Define the priorities & deadlines

• Ask if this possible to not add new requests during your absence (bugs not included)

• Check all new client’s requests / dedicated scope for the projects

• Make sure tasks’ statuses are up-to-date

• New tasks should be created in the Jira project

• Clear & specific description should be added to all tasks

• Assignee should be added to each task

• Due dates & priorities should be inserted for each task

• Check & make sure project documentation is up-to-date

• Accesses file

• Project Passport

• Meeting notes

💻 Internal communication & handover

• Make a call w/ team & responsible PM for each project

• Discuss the scope which should be done during your absence

• Make sure everyone (team & responsible PM) understand tasks and all questions/details are specified in the task’s description

🏝Enjoy your vacations!

 Overview

Planning of the project is an important part of management. It is a requirement before starting the project in order to understand when it is started, processed and finished. It helps to plan the resources, project execution and testing.

Flow

• When there is a ready to go scope, all of the tasks and epics must be entered into Jira and added estimation time.

• If the resources are already known, it is important to assign tasks to each member of the team

• Afterwards it is important to make a planning with all the further sprints and divide the tasks into them. 

• There will be also major tasks within each projects, that will be on a daily basis (communication) and at the beginning of the project (environment creation)

• Schedule daily meetings with the team in the calendar via zoom and create a space in Confluence for notes

---

 Tips and tricks


• If the project is small (2-3 months), it might be better to work with 1 week sprints and show a demo once in 2 sprints

• If the project is medium or big (3 months and beyond), it is better to work with 2 week sprints and have a demo with the customer each sprint

• Planning for medium and big projects must be done with the whole team (or at least with the teamleads)

 Overview

Estimation of a project is not always an easy process. It requires a full understanding of the incoming information, perseverance on what is being estimated.

 Estimation Flow

• When the first time the customer contacts the sales manager with all incoming information, the sales manager will have the new template for estimation already. Sales Manager is required to fill in the brief and the stakeholder register.

• PMO assigns a PM based on the requirements for the estimate, along with the developer(s) and QA for the estimation (sometimes, the PM will choose the developer(s) himself)

• The incoming documentation must be read by the PM, developers and QA

• There will be a new template for estimation that will be shared with the customer.

• The estimation must be based upon the incoming documentation from the customer. 

• The primal Estimation should be High Level, based on epics or main functions. 

• The Team Register should be filled in by the PM

• All the epics and main functions are to be entered by the PM and the developers estimating.

• After the customer agrees on the proposal, the estimation should be decomposed into tasks and be more detailed.

• Based on the total tasks hours, it is to be counted and added the time required for communication, planning, environment etc. For communication for daily meetings – 15 min per team member for each day. For planning it is approximately 1 hour per sprint (depending on the size of the project), for the environment – 8-16 hours depending on the dev.

 Tips and tricks


• If there is not enough incoming information, risks should be considered as well.

• In case of risks, the presumptions should be also written along with the percentage of the risk

• Risks can be added in percentage and discussed with the PMO.

 Overview

Communication with the customer is one of the main aspects of a successful project. It is very important for the communication to be agile, straight to the point and on a truthful basis. Since we are professionals, there will be implemented certain flows in order to make this process more correct from a professional point of view.

Communication flow

• All communications with the customer must take place in slack / via email.

• After each call with the customer, there should be an email / message follow up with the bullet points discussed.

• Since we are aiming for less documents to be and all in one place, there will be a document implemented, where all of the main info aspects of the projects remain, such as – primal estimation, communication map with the stakeholder, list of developers, change request/bugs document, questions and answers.

• Of course, the project passport will remain in Jira, however this document will be shared with the customer.

• The change requests will be estimated one by one and added by the customer along with the description. After confirmation from the customer  – we will take it into work (this sprint or the next).

• All important decisions must be traced in an email / message in Slack. It is a 100% must. All agreed new changes/new requests with the hours especially. They are also to be added to the Project space as an update.

• All change requests from the customer are to be informed to the team.

• All calls must be in the calendar scheduled with all of the required participants.

• Never have a customer wait. Provide updates to this or that task before the customer asks you. Make sure that if you promise update within a specific period of time, provide it. Even if the task is still in progress.

• Whenever the customer writes a message, and there is no time to reply, add the eyes sign – this will mean that you have seen the message and will reply within a couple of hours.
  Always reply to the customer`s message within a small period of time (1-2 hours max, better immediately) – in this case the customer will see that the message has been received

• if the sprint is one week, a report must be sent to the customer – worked tasks and hours (hours are optionally). If the sprint is 2 weeks, then such report is to be sent once in 2 weeks after sprint ends.

• Every two weeks, on Friday`s, a report with updates should be sent to the customer. What was worked, what issues happened along the way (optional), what are the plans for the next week or two.

• Every client must receive updates on the open tasks every 2 working days apart from the weekly reporting. Deliver a short yet concise message that includes the name of the task, its status and ETA.

---

 Tips and tricks


Here are some tips

• Never promise a customer something that you are not 100% sure of

• If there is something urgent required by the customer, and you are not sure if it is possible, or need a tip, always check with your PMO

• Always take responsibility for any action or any promise you give to the customer

• Be always proactive, update the customer every hour for an urgent task if it is even in progress

 Overview

Communication is one of the most important parts of any development process. It is the process that requires incredible soft skills in order to do the job correctly. In development there are certain rituals and best practices that are required. Such will be listed below.

 Communication Rituals


Here will be listed all the required Internal Rituals in regards to communication

Daily Stand Up Meetings

• All projects must have stand up meetings on a daily basis where all developers must be.

• The Daily meeting for each project must take not more than 15 minutes

• All Stand up Meetings must be scheduled in the Calendar with all of the participants on a daily basis

• All the stand up meetings must be noted in confluence with the Daily Standup meeting template

  

  Only titles of the table should be changed:
  Priorities – What was done?
  Progress – What is planned to be done?
  Problems – Blockers

• The notes must be taken in every confluence space of the project on a daily basis

• If you see that a lot of your developers are one multiple projects, you can combine the standup, but notes are to be added to each project separately.

• Communication must be logged separately in a communication task for each developer separately.

---

• Use Zoom in order to record a meeting if you feel it is required

• Make sure that everything is being told straight to the point, in order to “not waste time on water”

• If somebody does not have an opportunity to join, the developer must write down the status in the slack channel, which will be added by the Project Manager to the confluence page

• Each project, even if a small one, should have a channel in slack with all the developers added in order for quick communication

• There will be 1:1 on a weekly basis with PMO