Analytics

Ensure all the metrics are configured as mentioned below for the Dev360 module -

DORA Metrics

You can configure DORA metrics (Cycle Time, Deployments, CFR, MTTR), with your specific internal process that may include Draft PRs, enforce correct branches for tracking, and use of Squash/Merge feature for streamlined commit history.

For detailed configuration steps, refer to each metric guideline in the links below -

Cycle Time

Deployment PRs

CFR

MTTR

Pull Request Configurations

[To be followed in your Git]

When Creating a PR

  1. Keep it small PRs should be focused and scoped. Big PR = slow review. Aim for one clear purpose - not a feature + refactor + bug fix in one.

  2. Write a clear title + description Explain what the PR does and why. Mention any trade-offs or edge cases. Bonus: link to related issues or tickets.

  3. Prefer regular merge over “Squash & Merge” Squashing may make the commit history look clean, but it hides valuable details:

    1. You lose the step-by-step progress of the work

    2. git blame and debugging becomes harder

    3. Contributions from multiple developers get flattened

    Preferred: Use regular merges to preserve meaningful commit history Avoid: Squashing unless it’s a one-off minor fix or explicitly discussed

  4. Group commits logically (if not squashing) Use commits to separate concerns - for example

    1. One for implementation

    2. One for tests

    3. One for cleanup or comments

  5. Mark WIP clearly Not ready for review? Add [WIP] or set as a Draft PR. Don’t surprise reviewers.

  6. Add tests (if needed) If you're changing logic, adding tests isn’t optional - it’s a kindness.

  7. Tag the right people Assign reviewers who know the context. Don’t just tag the whole team.

When Reviewing a PR

  1. Be kind, not vague “This is confusing” → ❌ “Could you rename this function to clarify what it does?” → ✅

  2. Review the intent, not just the code Understand why the change was made - not just whether the code “works.”

  3. Ask questions, don’t assume “Why was this approach chosen?” is better than “This is wrong.”

  4. Use suggestions generously Inline GitHub suggestions save time and foster a collaborative feel.

  5. Don’t let perfect block progress If the PR is good enough to ship, ship it. You can always improve later.

  6. Approve or request changes - don’t ghost If you open the PR, close the loop. Don’t leave people hanging.

Issue Tracker Configurations

[To be followed in your Issue Tracker]

Here are some best practices for your Issue tracker project management to fetch accurate data insights into Typo-

Project Structure

Issue Types

  • Epics: Large bodies of work that can be broken down

  • Stories: User-focused features or changes

  • Tasks: Technical work items

  • Bugs: Defects requiring fixes

Components

  • Organize by functional areas (Frontend, Backend, Infrastructure)

  • Limit to 5-7 main components

  • Use labels for more granular categorization

Workflow States

Standard Workflow

Backlog → To Do → In Progress → Review/QA → Done

Extended Workflow (for larger teams)

Backlog → To Do → In Progress → Code Review → Testing → Ready for Release → Done

Key Points

  • Keep states minimal but sufficient

  • Each state should represent a distinct phase

  • Avoid creating states for edge cases

  • Consider adding a "Blocked" flag rather than a blocked state

Issue Management

Fields to Maintain

  • Component

  • Priority (P1-P4)

  • Sprint

  • Story Points

  • Labels (for filtering)

  • Epic Link (when applicable)

Assignment Rules

  • Assign during sprint planning, not before

  • One primary assignee per issue

  • Use watchers for stakeholders

  • Consider team capacity before assignment

Developer Assignee Field

  • Single assignee per issue

  • Don't assign until sprint planning

  • Respect team member capacity (WIP limits)

  • Use watchers for additional stakeholders

Estimation

Story Points

  • Use Fibonacci sequence: 1, 2, 3, 5, 8, 13

  • Cap at 13 points - larger items should be broken down

  • Consider effort, complexity, and uncertainty

  • Don't assign points to bugs (use priority instead)

T-Shirt Sizing (Alternative)

  • Use for initial backlog grooming

  • XS, S, M, L, XL

  • Convert to points during sprint planning

Sprint Organization

Sprint Setup

  • Fixed duration (typically 2 weeks)

  • Consistent sprint names: YYYY-MM-DD Sprint XX

  • Set sprint goals

  • Maintain velocity tracking

Sprint Hygiene

  • Regular backlog grooming (bi-weekly)

  • Sprint planning meetings

  • Daily standups using the board

  • Sprint retrospectives

PR Linking

  • Link PRs directly to issues

  • Use standard naming: [PROJ-123] Brief description

  • Automated status updates via Git integration

Deployment

To set up deployment, you must integrate your CI/CD tool with Typo. Once integrated you can configure the settings using the configure button present on the top right corner.

Here are the detailed guidelines.

Resource Allocation

Setting Up Categories

By default, the data shown in investment distribution is based on your issue tracker ticket types. This can be configured as per your requirements. To set this up, use the "configure" button in the top right corner.

Here are the detailed guidelines.

Some commonly used categories by engineering teams are mentioned in the next section.

Investment Distribution Categories

Here are the core resource allocation categories in tech teams:

  • Features

    • New product development

    • Enhancements

    • Growth initiatives

    • Customer requests

  • KTLO

    • System maintenance

    • Critical bugs

    • Security patches

    • Production incidents

  • Tech Debt

    • Refactoring

    • Architecture improvements

    • Test coverage

    • Platform upgrades

  • Infrastructure

    • DevOps/CI/CD

    • Developer tooling

    • Monitoring

    • Scalability

  • Innovation

    • Technical spikes

    • Prototypes

    • New tech evaluation

    • Research

  • Support

    • Customer tickets

    • Operations

    • Data management

    • Compliance

Custom Reports

To create a custom report, navigate to the Custom Report section & click on the Create Report button located at the top right corner of the screen.

Here are the detailed guidelines.

Incidents

To set up incidents, navigate to the incident section and click on the configure button located at the top right corner of the screen.

Here are the detailed guidelines.

Initiatives

To set up incidents, navigate to the initiative section and click on the create button located at the center of the screen.

Here are the detailed guidelines.

PreviousPhase 2 - Metric ConfigurationNextCode Health

Last updated