Theme

Category: PM Team Space

  • Jira | Task flow guide

    Issue creation

    The PM creates an issue in Jira, and they should ensure, that the issue has the following fields filled in:

    1. Title: The PM should use a clear and concise title in a Summary field – it has to be a page name or a block name that will be later used in the admin panel.

    image-20240409-145400.png

    1. Issue Type: Select the appropriate issue type

    image-20240409-145516.png

    • Epic – is used for the complex pages or blocks that will be later broken into smaller tasks.

    • Story – is used for describing sections/blocks on pages, and other functional elements in the project.

    • Task – is used for general tasks.

    • Bug – is used for bugs spotted during QA review.

    • CB – is used for bugs that were noticed by the client, and are not billable.

    • CR – is for additional requests made by the client after review, and are billable hours.

    1. Description: Provide a detailed and clear description of the task.

    Provide a detailed and clear description of the task with linking to the confluence page (Epic/Story).

    image-20240409-145551.png

    1. Priority: Set the priority level (e.g., low, high, urgent).

    image-20240409-145621.png

    1. Due Date: Set a deadline if needed.

    image-20240409-150039.png

    1. Original Estimate: The PM should assign an estimate if provided by the developer.
      If the PM does not have an estimate, it must be added by a developer after they move the issue to ‘In progress’ status.

    image-20240409-150224.png

    1. Assignee: The PM should assign the task to a team member.

    image-20240409-150420.png

    If any of the fields listed above is missing, here are short tips on how to add it.

    How to add an issue type
    image-20240429-143101.png
    How to edit issue layout (adding a Due Date works the same way)
    image-20240429-143634.png

    Issue completion

    1. The developer should drag an issue to In Progress status.

    2. Before starting to work on the task, the developer should start tracking time using TimeDoctor.

    3. The developer should familiarize with the task requirements.

    • If clarification or additional resources are needed, the developer should move the task to Dev Blocked status, add a comment to the issue card, and add a message in the Slack channel of the project, tagging the PM and letting them know that the task is blocked.

    If the issue is moved to Dev/QA Blocked, the developer/QA should briefly describe the blocker in the issue’s comments.

    • If the description is clear to the developer, they should add an Original Estimate (if missing) and start working on the task.

    1. Once the developer completes the task, they should add a comment with links to the merge request for the front end or stage for the backend.

    When the task is moved from In Progress to Code review, the developer needs to provide a link to the merge-request, and briefly explain what has been done in the comments to the issue. Additionally, provide screenshots and instructions for QA in the QA Scope field.

    1. If the issue has been moved from Front-End developer to Back-End developer or vice versa: dev needs to briefly describe why it was moved and what was done, provide instructions to the team member

    Code Review

    1. The developer should move the issue to Code Review status and assign the issue to the Team Lead.

    Code review is performed for a page or block; bugs or small support tasks do not go through code review.

    1. The Team Lead reviews the task. They should:

    • Check the time spent and estimated time.

    • Conduct code review.

    • Provide feedback in the comments on the issue.

      • If satisfactory, the TL should assign the task to the PM and move it to Ready for QA status.
        The PM should assign the task to the QA when the block/page is ready for testing.

      • If changes are needed, assign the task back to the developer and revert to In Progress status.
        In this case, the developer should implement the comments provided and pass it for Code review again. This process repeats itself until all the comments from TL are fixed.

    Quality Assurance (QA)

    1. The QA should review the task in Ready for QA and drag it to QA in Progress status.

    2. The QA should conduct the testing and create relevant issues (issue type – bug) for any bugs found. The issues should be linked to the original issue and assigned to the developer.

    If the QA discovers bugs that belong to one section or scope, these bugs can be combined into one issue. In this case, the QA should describe every bug as separate paragraphs in the Description field and add a checklist to the issue.

    1. The task is in the QA in Progress status until all linked bugs are fixed and approved by the QA.

    2. When all linked bugs are fixed, the QA should drag the task to QA Approved status and assign the issue to the PM.

    QA Approved status means that the issue is completed, fully tested, and ready to be released to live.

    Once the issue has been moved from QA in progress to QA Approved, the QA should provide screenshots or videos that confirm the task has been completed, and provide information on the testing environment and devices.

    Deployment

    1. The PM communicates with a client whether to deploy the task.

    2. When the decision is made, the PM should drag the task to Ready to Merge in Master and assign it to the developer.

    When the issue is moved from QA Approved to Ready to Merge, the PM should provide brief instructions to the developer on the merge timing and important details.

    1. The developer deploys the task to the master branch, moves the issue to Deployed to Master, and assigns the QA.

    2. Once the QA tested the task or checklist on Live, the QA should move the issue to Done, and assign the PM/Client to the issue.

    The developer deploys the task to the master branch, moves the issue to Deployed to Master, and assigns the QA.

    1. Once QA tested the task OR checklist on Live the ticket should be changed by QA to the status Done and assigned to the PM/Client.

    The QA should also provide screenshots or videos that confirm the task has been completed, and provide information on the testing environment and devices. If the issue was checked using a common checklist for live, just report it.

    1. The QA or the PM should create a Release – responsibility for the Release creation should be discussed between project participants.

    2. The QA should review all tasks within the release on the production environment.

    If any bugs are found post-deployment, the QA should create a separate issue with a scope of tasks, assign the issue to the developer, and link them to the original issue.

    How to use the Releases feature?

    Instruction

    1. On the sidebar, find the Releases page, and use the Create version.

    image-20240410-224226.pngimage-20240410-224323.png

    1. When creating a new version, use a release date as a title – e.g. Version 15.05.24, add the dates, and save.

    image-20240410-224407.png

    1. You have created an Unreleased Version with the following view.
      The driver is the person who created the Release.
      The driver should add Approvers, people on the team who will review the tasks that are going to be released.

    image-20240410-224818.png

    1. The Driver should add issues to a Release. Type your project’s key to find the issues needed.

    image-20240410-225110.png

    1. When the issues are added, the Driver will see the progress on the issues added to a Version. When the QA reviews all tasks within the release on the production environment, the version can be released in the top right corner of the Release page.

    image-20240410-225659.png

    Important communication aspects

    1. When the issue has been moved from FE developer to BE developer, or vice versa, the previous developer should briefly describe what has been done and why the issue has been moved in the issue’s comments in Jira.
      Provide brief instructions to the team member who you are passing the assignment to.

    2. If the developer provides any suggestions regarding the task, it should be written in the issue’s comments in Jira. It is also connected to cases, when the task needs to be postponed, other solutions are being proposed, etc.

    3. Any important questions and topics regarding tasks should be discussed in the issue’s comments in Jira, not in Slack.

    4. If a team member has any suggestions or questions, they should tag the team member who can answer your question. In case of urgency, also notify in the project’s channel in Slack.

  • Projectrack | Reporting

    Project set up

    When the project is created, and all the necessary details are set up, head to the Project data section.

    There is a 3-column layout comprising Project Details, Updates, and Involved parties.

    1. Project Details

    This section is the broadest and needs to be filled when the project starts. There is an extensive set of fields that can give a bigger perspective on the project, which is necessary for the sales team. This way, the sales team can know the diversity of tools and technologies we can use in clients' projects.

    The project details section contains a set of questions set up as dropdown questions with the option of multiple selections. If the dropdown doesn't have some choices, you should contact the Operational Manager to add the missing answer.

    Please note! Some of the fields in this section are default Jira fields; you should do this from the Project settings page to edit them.

    2. Updates

    This section is dedicated to regular updates and keeping statuses up to date.

    This is the part you will be working with the most often.

    3. Involved

    This section should be filled with info about the team working on the project and any third parties or associated projects, if any.

    To comfortably edit all the fields at the start of the project, use the following link:

    https://cheitgroup.atlassian.net/plugins/servlet/ac/com.deiser.jira.profields/project-navigator?project.key=EI&project.id=10187#!v=2541&t=list

    This view contains all the information necessary for our sales team, also filtered to show only YOUR projects. So, it is the way to fill project details for all projects more quickly and conveniently.

    Regular updates

    Here is the most essential part – status and updates. But it would be much more comfortable to edit these values inside Projectrack itself.

    You can choose the view created to filter all the projects you manage. After that, you will be able to edit any values straight in the table, with it saving automatically.

    History

    If you need to find any ‘historic’ details about statuses, stages or updates change to track progress or create a bigger report on the project, you should return to Jira → 'Project' → Project info → 3 dots in the top right corner → History.

    There you’ll see a table with every update made in the project values sorted by newest. You can export this info into CSV file, and if needed, transform just the way you need it.

    Procedure

    1. When creating a project, fill in all the fields with Project details and involved parties.

    Project details fields

    1. Domain – must reflect client’s business specific (what client does).

    2. Project type – must reflect the specific of the project on our site (what we develop).

    3. Category – should be included (needed for filtering).

    4. Country – country of client’s business HQ location.

    5. Description – one-sentence description of the project.

    6. Detailed description – broad description of the project that would help our sales team to search for similar prospects. Should include details about the client’s goals and project’s objectives, implemented solutions, tech stack, etc.

    7. Partners – should include partners that we collaborate with on the project, if there are any

    8. Awards – add the link to the award if the project is nominated for any awards

    1. Update project statuses and updates on the regular basis.

    Some tips to enhance your reporting;)

    • Check the fields Status, Budget ETA – these fields should contain correct information, do not forget to update them if something changes.

    • Make sure that Status Update field contains ‘readable’ text – proper formatting, with bullet points, also do not forget about proper punctuation. Using Grammarly or similar tools might help;)

      (синяя звезда) 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 most often asks you about in DMs or at meetings, you definitely need to pay attention to this in the report (wink)

    Fields that have to be reviewed regularly

    1. Status
      – On track – everything is going well
      – At risk – medium level of issues arising
      – Off track – issues that need immediate reaction and action
      – Archive – inactive projects

    2. Phase – should reflect the current stage of the project
      – Discovery – for the projects that are on the stage of estimation and negotiations regarding the details, before we start the full-scale work on it.
      – Design – for the projects that are being on design development stage.
      – Development – for the projects that are being developed at the moment.
      – Pre-launch – for the projects that are getting prepared to the launch.
      - Launched – this phase can be assigned to the project during a month after the launch. Afterwards you should change it to Support or Closed.
      – Support – Projects that are maintained by our team.
      – On hold – projects that are currently paused, but are to be continued.
      – Closed – Projects that have been successfully launched and we do not longer support them, or projects that have been archived without a launch.

    3. Initial ETA (for projects on Support – not necessary)

    4. Current ETA (for projects on Support – not necessary)

    5. Estimated budget

    6. Spent budget

    7. Additional requests estimated

    8. Additional requests spent

    9. Team – has to be updated on a monthly basis.

    10. Status update
      Should be updated on a weekly basis, properly formatted.
      Please, start your update with dates in the following format – DD.MM–DD.MM (e.g. 19.02–23.02)

    11. Last update
      Should be updated on a weekly basis.
      Please, fill in the format – DD.MM and link (to the screenshot of a message or email to the client).

    Please, note! Updates should be filled every Monday by 11:00.

    After filling Projectrack, be sure to notify the team in the Slack channel #pmo-reports in the following format (by separate message, NOT in the thread):

    Привіт!

    Заповнив/ла апдейти по проектах в Projectrack. Моменти, на які варто звернути увагу:

    • проект 1

    • проект 2

    Посилання на мої проекти в PT (посилання на лінк з таблиці вище – ваша вью).

  • Project Closure | Internal procedure

    (синяя звезда) Introduction

    This document is your guideline to the project closure and reporting. Our goal is to analyse processes and outcomes to identify best practices and address our weak spots.

    At the start of the Discovery phase, the PM should create a Project Sheet (using this template), where an estimation, timeline and the stats would be filled. The PM should insert there the actual timeline and estimation breakdown at the start of the project.

    Along with that, the PM should create a document for retrospective meetings, using the following template. The team involved in the project should be notified when the project starts, and the PM should share and pin the retrospective document in a project channel in Slack.

    The PM should encourage the team to add current issues or notes related to the project – team communication, project management, tasks, client expectations, development, or QA issues.

    At the end of the project, the PM must remind the team to fill the documents with their issues or notes and ensure that everyone on the team has provided their feedback. The PM also can include their comments if they consider it necessary.

    (синяя звезда) Retrospective Meeting

    Reccurency

    • A final retrospective must be conducted at the end of every project, after go-live (maximum 2 weeks after go-live), and receiving feedback from the client.

    • For projects lasting more than 3 months, retrospectives should occur every 3–4 weeks, during which feedback and data are collected and updated in a rolling report.

    Pre-retro preparations

    1. PM should notify the team about the call at least 3 days in advance, sending an invitation to relevant stakeholders (developers, team leads, PMO team, etc.). PM should gather the entire team, including the dev team leads, for the retrospective call.

    2. Before the retrospective, the PM should review all team comments, and analyze and consider theoretical steps for improvements, which will then be discussed with the team on the meeting.

    Before the final retrospective, the PM should fill General Stats and Detailed stats in the Project Sheet with the actual numbers available in the easyBI dashboard “Project Report Sample”.

    For this statistics, use this template.

    1. General stats

      1. Estimated & Spent time (FE, BE, QA, bug fixing, etc.)

      2. Comments to every component where time spent exceeds the estimate

      3. Bugs quantity and time spent for bug fixing

      4. List of the project’s team members

    2. Detailed stats

      1. Estimated & Spent time per page

      2. Comments to every page where time spent exceeds the estimate

    Where to take numbers from easyBI and where to paste it

    1. Go to Jira > easyBI > Dashboards > Project report sample.
      There you have 3 widgets, needed to fill the Project sheet with numbers.

    image-20241218-154425.png

    1. Choose your projects in the widgets.

    General stats

    To fill this page, you will use widgets Time Spent per Project and Bug fixing. Totals and Delta here are counted automatically, so you will have to copy&paste only the numbers for estimate and spent.

    genstat.png

    Then, if we have exceeded the estimate, the cells in the Delta column will become red. That means that at the retrospective meeting you will have to discuss that with the team, and as a result – provide the reasoning behind exceeding the estimate in the comment section on the right.

    Detailed stats

    To fill this page, you will use Time Spent per Page widget. Totals and Delta here are counted automatically, so you will have to copy&paste only the numbers for estimate and spent.

    detstat.png

    Then, if we have exceeded the estimate, the cells in the Delta column will become red. That means that at the retrospective meeting you will have to discuss that with the team, and as a result – provide the reasoning behind exceeding the estimate in the comment section on the right.

    (синяя звезда) Retro Call Agenda

    1. Call opening

    • Start by thanking the team for their collaboration.

    • Share the key project statistics prepared in advance:

      • Estimate vs. Actual time spent and their differences.

      • Bug statistics.

      • Any overtime instances.

    1. Later, the PM should act as a facilitator, allowing each team member to speak in turns to discuss their written points and overtime instances.

    PM should monitor the team’s mood, prevent personal conflicts, and smooth over conflicts if necessary.

    1. PM should identify points for future improvement and keep track of them on a list.

    2. At the end of the retrospective, the PM should summarize the action plan for the discussed improvements.

    (синяя звезда) Post-Retro Actions

    PM should fill out the Retrospective findings document with their project’s information and share the project’s conclusions at the following PM call on Friday to share experiences with other PMs.

  • Client briefing

    Company Profile

    • Current website:

    • Domain:

    • Business goals:

      • Goal 1

      • Goal 2

    • Project goals:

      • Goal 1

      • Goal 2

    • References:

    • Languages (one / multi-language):

    • Future plans (MVP only or a bigger scope):

    Project Details

    Budget

     

    Rate

    Deadline for estimation

     

    Deadline for the project

     

    Needs design?

     

    Needs help with adding content?

     

    Technical Specifications

    Preferred tech stack

     

    Preferred integrations

     

    Needs SEO optimization? If yes, for what pages?

     

     

  • Estimation templates 2024

    Main template: https://docs.google.com/spreadsheets/d/1rt96D0eph8FRupm3tDI13dmGkr7DsnYS/edit?usp=sharing&ouid=105221401777517225043&rtpof=true&sd=true

    More configurations: https://docs.google.com/spreadsheets/d/1vmLOjOFAD1KdAv7c_Mg2GYxSnjz7wMKt/edit#gid=1471622098

    Client one price estimate (without range): https://docs.google.com/spreadsheets/d/1mk8d5FJ_UURutOdIQuDD72PZe8JqIibv/edit?gid=1471622098#gid=1471622098

    Presentation: https://www.figma.com/file/SLBjwEsB6dIp4V0oFIihQW/cheit-presentation?type=design&node-id=42-288&mode=design&t=5X5px8I0W1sfIPDD-0

    Examples:

    Team:

    Client:

    Presentation: https://www.figma.com/file/lJ4jORjEg9J5UB4EGTsH1e/Agora-FM-Development-pre-proposal-presentation?type=design&node-id=0-1&mode=design&t=o3PrZqFvtTwaFbt3-0

  • Story 1. Name

    General info

    Any general description here

    User story

    As a …

    I want …

    So that …

    Visual design:

    Desktop:

    Mobile

    Acceptance criteria

    01

    Given:

    When:

    Then:

    image, wireframe, screenshot form design

    02

    Given:

    When:

    Then:

    image, wireframe, screenshot form design

    03

    Given:

    When:

    Then:

    image, wireframe, screenshot form design

  • Epic 1. Name

    General info

    General description

    Epic ticket:

    User stories

    Visual design

    Desktop:

    Mobile:

  • Project Scope templates

    Epic 1. Name

    Story 1. Name

    Presentation: https://docs.google.com/presentation/d/1hTqLxXYTjgxg0TS6QSQEdNg_n4jh_T38Mrg8Iu7nOj0/edit?usp=sharing

  • Project Scope

    Jira

    Use all basic types of tickets in Jira: Epic, Story, Task, Subtask, Bug.

    Epic: page, big functional block, additional subproject

    Story: user story and acceptance criteria (Gherkin format)

    Task: general tasks (Team collaboration, setup the project, estimation, investigation, deploy, server tasks, etc)

    Subtask: criteria of user story or additional subtask for team member

    Bug: info of mistake with steps to reproduce and link to the Scope in confluence

    Confluence

    Add to space of the project Scope page as a shortcut.

    Scope includes: Big functional section → Epic → Story and acceptance criteria

    image-20240221-071826.png

    Epic in confluence

    • General info – general description of the epic in any form

    • Link to Epic ticket

    • Links to User story tickets

    • Visual design – files or links

    image-20240221-072120.png

    Story in confluence

    • General info – general description of the User story in any form (may include additional context of the task)

    • User story (feature)

    • Visual design – Design files or links to them, other additional links (email templates, API documentation, etc.)

    • Acceptance criteria Gherkin (Given, When, Then) in a table view, where the first column is the numbering of the criteria, the second column is the scenario, the third column is a screenshot from the design or Wireframe of how it should look (not the way it is now, but how it should be).

    image-20240221-072434.png

    Gherkin format

    User story (feature)

    • Given: context, page where to log in

    • When: some event or user action

    • Then: what we get as a result

    • AND: if you need to add/get several scenarios, actions, results

    Bug report

    • Actual result: text description of the bug reproduction

    • Expected result: text description of how it should work (link to the page with Acceptance criteria)

    image-20240221-072908.png

  • Retrospective template

    (синяя звезда) Інформація про ретроспективу

    Ініціатор

    Причина проведення:

    Дата проведення:

    Учасники:

    (синяя звезда) Ретроспектива

    Додайте у таблицю пункти, які ви хочете почати, перестати чи продовжити робити. Можна додавати пункти виходячи з того, що вам сподобалось чи не сподобалось на проєкті.

    Продовжити робити

    Почати робити

    Перестати робити

    Учасники

    (синяя звезда) Детальний розбір пунктів наведених у таблиці вище

    Інструкції

    Опис

    Учасник

    Учасник

    Учасник

    Учасник

    Учасник

    Учасник

    (warning) Попередні обставини

    Перелічіть у хронологічній послідовності події, які призвели до інциденту.

    (синяя звезда) Помилка

    Опишіть, у чому проявляється некоректна робота внесених змін. Якщо можливо, доповніть візуальним представленням даних.

    (синяя звезда) Вплив

    Опишіть, як інцидент вплинув на внутрішніх і зовнішніх користувачів. Вкажіть кількість звернень до служби підтримки.

    (синяя звезда) Виявлення

    Зафіксуйте, коли і яким чином команда виявила інцидент. Опишіть, яким чином команда могла б виявити цей інцидент швидше.

    (синяя звезда) Реакція

    Повідомте, хто відреагував на інцидент, які заходи було вжито і коли. Вкажіть, які були затримки або перешкоди для реагування на інцидент.

    (синяя звезда) Відновлення роботи

    Зафіксуйте, що було зроблено з метою зниження негативних наслідків для користувачів і коли інцидент було усунуто. Опишіть, яким чином команда могла б усунути негативні наслідки швидше.

    (синяя звезда) Хронологія

    Вкажіть терміни роботи над інцидентом. Додайте інформацію про попередні обставини, події після інциденту, а також про будь-які рішення та внесені зміни.

    (синяя звезда) Виявлення першопричини за методикою "П’ять "Чому""

    Проведіть аналіз «Пять причин», щоб визначити справжні причини інциденту.

    (синяя звезда) Визначення першопричини без пошуку винних

    Позначте кінцеву першопричину й опишіть, що потрібно змінити (при цьому не шукайте винних), щоб не допустити подібних інцидентів у майбутньому.

    (синяя звезда) Вивчення беклога

    Подивіться, чи немає в беклозі розробки не внесеної до плану роботи, яка могла б запобігти інциденту або пом’якшити його наслідки.

    (синяя звезда) Пов’язані інциденти

    Перевірте, чи не було в минулому інцидентів з такою самою першопричиною. Зазначте, яких заходів щодо зниження негативних наслідків було вжито для тих інцидентів, і з’ясуйте, чому подібний інцидент повторився.

    (синяя звезда) Уроки

    Опишіть, що ви дізналися, що вийшло і що можна поліпшити.

    (синяя звезда) Подальші дії

    Перелічіть завдання Jira, які були створені, щоб запобігти подібним інцидентам у майбутньому. Позначте, хто несе відповідальність, коли ця людина має виконувати свою роботу і де ця робота відстежується.

    (синяя звезда) План дій для покращень

    •