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 -
Pull Request Configurations
[To be followed in your Git]
When Creating a PR
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.
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.
Prefer regular merge over “Squash & Merge” Squashing may make the commit history look clean, but it hides valuable details:
You lose the step-by-step progress of the work
git blame
and debugging becomes harderContributions 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
Group commits logically (if not squashing) Use commits to separate concerns - for example
One for implementation
One for tests
One for cleanup or comments
Mark WIP clearly Not ready for review? Add
[WIP]
or set as a Draft PR. Don’t surprise reviewers.Add tests (if needed) If you're changing logic, adding tests isn’t optional - it’s a kindness.
Tag the right people Assign reviewers who know the context. Don’t just tag the whole team.
When Reviewing a PR
Be kind, not vague “This is confusing” → ❌ “Could you rename this function to clarify what it does?” → ✅
Review the intent, not just the code Understand why the change was made - not just whether the code “works.”
Ask questions, don’t assume “Why was this approach chosen?” is better than “This is wrong.”
Use suggestions generously Inline GitHub suggestions save time and foster a collaborative feel.
Don’t let perfect block progress If the PR is good enough to ship, ship it. You can always improve later.
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.
Last updated