Project Management Tools

Overview: The Language of Professional Teams 🗣️

Why this matters:

Interview Question:
"Have you worked with Agile teams?"

If you say "What's Agile?"
→ Red flag! 🚩

This doc teaches you the language
professionals use every day!

As a developer, you'll work with:

• Project Managers → Set priorities
• Product Owners → Define features
• Scrum Masters → Remove blockers
• QA Engineers → Test your code
• Other Developers → Build features together

They'll use terms like:

• "Add this to the sprint backlog"
• "Create a ticket with ACs"
• "We need 2 story points for this"
• "Let's discuss in retro"

Don't worry! By the end of this doc, you'll speak their language fluently!

Software Development Methodologies

Software development methodologies are the way of developing software. There are much software development methodologies available in the market. Some of them are:

• Agile
• Waterfall
• Prototype
• Rapid Application Development
• etc

I will not go into the details of these methodologies. You could read about them on the internet. I will just talk about agile.

Agile Methodology 🔄

Waterfall vs. Agile: The Key Difference

Waterfall (Old Way):

Plan → Design → Build → Test → Deploy
 ↓      ↓       ↓      ↓       ↓
Takes 6-12 months for ONE release
If requirements change → Too late!

Agile (Modern Way):

┌────────────────────────────┐
│ Sprint 1 (2 weeks)         │
│ Plan → Build → Test →      │ ← Deploy!
│ Get feedback               │
├────────────────────────────┤
│ Sprint 2 (2 weeks)         │
│ Plan → Build → Test →      │ ← Deploy!
│ Adapt based on feedback    │
└────────────────────────────┘

Continuous releases every 2 weeks!
Can change direction quickly!

The Agile Philosophy

Key principles:

🎯 User satisfaction FIRST
   → Not heavy documentation

🔄 Embrace change
   → Requirements will change, that's OK!

⚡ Deliver frequently
   → 2-week sprints, not 6-month projects

🤝 Collaboration
   → Daily communication with team

🚀 Working software
   → Show real features, not just plans

The Restaurant Analogy:

Waterfall:
  Plan ENTIRE menu for 6 months
  → Don't know if customers like it until then!

Agile:
  Launch 3 dishes this week
  → Get feedback
  → Adjust menu next week based on what sells

Why Agile Won

Agile is popular because:

• Software changes fast (requirements evolve)
• Users want features NOW (not in 6 months)
• Feedback loops prevent wasted work
• Teams stay flexible and responsive

95% of tech companies use Agile in 2025!

Scrum

Scrum is an Agile framework for managing and completing complex projects, particularly software development projects. It provides a structured approach to implementing Agile principles and practices by breaking the development process into small, time-boxed iterations called sprints.

Scrum consists of three primary roles:

1. Product Owner,
2. Scrum Master, and
3. Development Team.

The Product Owner is responsible for defining the project goals, prioritizing the product backlog, and communicating with stakeholders. The Scrum Master is responsible for facilitating the Scrum process, removing obstacles, and promoting collaboration and self-organization within the team. The Development Team is responsible for designing, developing, testing, and delivering working software during each sprint.

Scrum also includes several ceremonies, such as sprint planning, daily Scrum, sprint review, and sprint retrospective. These ceremonies provide opportunities for the team to plan their work, review their progress, and identify areas for improvement. The artifacts of Scrum include the product backlog, sprint backlog, and increment, which are used to track progress, prioritize work, and ensure that the team is delivering a working product increment at the end of each sprint.

I have mentioned sprint in the above paragraph. I will explain with details down below.

Roadmap

A roadmap is a high-level visual representation of a plan or strategy, outlining the goals, objectives, milestones, and timelines of a project or initiative. It provides a clear picture of the planned activities and outcomes, helping stakeholders to understand the overall direction of the project. A roadmap is typically created early in the project and may be updated periodically as priorities and goals shift.

Roadmap usually consists of epics, etc.

Epic

An epic is a large user story that can be broken down into smaller user stories. It is used to group tickets together. Normally, an epic is created for a feature.

For example, there is a feature called User Management, and this feature can be broken down into a number of smaller tickets like User Registration, User Login, User Profile, etc. So, we can create an epic called User Management and add all the tickets related to User Management feature to this epic. Epic will help us to track the progress of the feature as we can see all the tickets related to the feature in one place and can see how many tickets are completed, how many are in progress, and how many are left.

Backlog

A backlog is a prioritized list of tasks or user stories that need to be completed to achieve the goals outlined in the roadmap. It serves as a repository for all the work that needs to be done (all the tickets that are created for the project) and is constantly updated to reflect changes in priorities or requirements. The backlog is maintained by the Project manager, product owner, or business analyst, etc, and the development team selects items from the backlog to work on during sprints.

The tickets are prioritized by the product owner or the project manager based on the business value of the ticket and tickets with the highest business value are prioritized first. The tickets which are prioritized are added to the sprint backlog

Sprint: The Heart of Agile 🏃‍♂️

What Is a Sprint?

Think of sprints as race laps:

Marathon (Waterfall):
  └─ Run 26 miles straight → Exhausting, risky

Sprint Series (Agile):
  ├─ Sprint 1: Run 400m → Rest → Review
  ├─ Sprint 2: Run 400m → Rest → Review
  └─ Sprint 3: Run 400m → Rest → Review
     ↓
  Sustainable, adjustable pace!

Definition:

• Time-boxed: Fixed duration (usually 1-4 weeks, typically 2 weeks)
• Goal-oriented: Deliver specific features
• Repeating: Continuous cycle

Visual Flow:

┌────────────────────────────────────┐
│         Sprint Cycle (2 weeks)     │
├────────────────────────────────────┤
│ Mon: Planning → What to build?     │
│ Tue-Thu: Execution → Build it!     │
│ Fri: Review → Show stakeholders    │
│ Fri PM: Retrospective → Improve    │
└────────────────────────────────────┘
        ↓ (Next Monday)
┌────────────────────────────────────┐
│      Next Sprint Begins...         │
└────────────────────────────────────┘

The 4 Phases of Every Sprint

1. Planning  → 🎯 Choose work
2. Execution → 💻 Build features
3. Review    → 📊 Demo to stakeholders
4. Retro     → 🔄 Learn and improve

Let's dive into each phase!

Sprint Planning

During this phase, the team gathers to plan the upcoming sprint. The product owner discusses the prioritized user stories or backlog items with the team. The team estimates the effort required for each item and collectively determines which items can be completed within the sprint timeframe. The result is a sprint backlog that defines the work to be accomplished in the sprint.

For example in the sprint planning phase, product owner might involve presenting a list of user stories, such as "As a user, I want to be able to create an account." The team estimates the complexity and effort required for this user story and selects it, along with other stories, for the upcoming sprint.

Sprint Execution

This phase is the core of the sprint, where the team actively works on the items in the sprint backlog. The team collaborates closely, breaking down the selected user stories or tasks into smaller, manageable tasks. They execute the development, testing, and any necessary activities to deliver the agreed-upon increment of work.

Sprint Review

At the end of the sprint, the team conducts a sprint review meeting to showcase the completed work to stakeholders and gather feedback. They present the increment achieved during the sprint, demonstrate the implemented features, and gather input from stakeholders for further refinement. The review provides an opportunity to assess whether the sprint goals were met and to adjust the product backlog accordingly.

Sprint Retrospective

Retrospective means looking back on or dealing with past events or situations. The sprint retrospective is a crucial phase for continuous improvement. The team reflects on the sprint's process and outcomes, identifying what worked well and what can be improved. They discuss the team's performance, communication, and collaboration, aiming to enhance their effectiveness in future sprints. The retrospective helps the team learn from their experiences and make necessary adjustments for ongoing development.

Retro is an open discussion where everyone in the team can share their thoughts on the sprint. Everyone in the team tells it's 4Ls, which are:

Liked

In this step, team members share the aspects of the sprint that they liked or found valuable. It could include positive experiences, successful practices, or accomplishments. By highlighting what went well, the team reinforces positive behaviors and acknowledges the strengths of their work.

Learned

The "learned" step focuses on identifying the lessons and insights gained during the sprint. Team members discuss the knowledge they acquired, both technical and process-related, throughout the iteration. This could involve sharing new skills, best practices, or discoveries that can be applied to future sprints.

Lacked

During this phase, the team discusses the areas where they felt something was lacking or could be improved. It could be related to resources, tools, communication, or any other factors that hindered their progress or effectiveness. Identifying the gaps or deficiencies helps the team address these issues in subsequent sprints.

Longed For

The "longed for" step involves discussing the aspirations and desired improvements the team envisions for the future. It allows team members to express their hopes, ideas, or suggestions for enhancing their work environment, processes, or outcomes. This step encourages creative thinking and provides an opportunity to strive for excellence.

The 4 Ls framework promotes open and constructive discussions, enabling the team to celebrate successes, learn from challenges, address shortcomings, and set goals for continuous improvement. It encourages a collaborative environment where everyone's perspectives are valued, fostering a culture of learning and growth within the team.

Ticket: Your Daily Work Unit 🎫

The Movie Ticket Analogy:

Movie Ticket → Specific show, time, seat
Work Ticket  → Specific task, details, assignee

What is a ticket?

• Smallest unit of work
• Created by Project Manager/Product Owner
• Tracked in tools like Jira, Trello, etc.
• Your daily assignments!

Ticket Lifecycle (The Journey)

Every ticket goes through these stages:

📝 Created
   ↓
📋 To Do (waiting in backlog)
   ↓
✅ Selected for Development (added to sprint)
   ↓
💻 In Progress (you're coding!)
   ↓
🔍 In Review (PR created, waiting for reviewer)
   ↓
👀 Under Review (reviewer checking code)
   ↓ (if issues found)
   ↓ ←─────┐
💻 In Progress│ (fix feedback)
   ↓         │
🔍 In Review─┘ (resubmit)
   ↓ (approved!)
🧪 QA (testing team verifies)
   ↓
✅ Done (deployed to production!)

Ticket Anatomy (What's Inside)

Tickets have many fields - here's what each one means:

1. Ticket Number
2. Title
3. Description
4. User Story
5. Acceptance Criteria (AC)
6. Priority
7. Status
8. Type
9. Assignee
10. Reporter
11. etc

Ticket Number

It is automatically generated when the ticket is created used to identify the ticket. For example, #1, #2, #3, etc.

Title

Short description of the ticket in one line to give an idea about the ticket.

Description

Detailed description of the ticket. It should be written in the following format:

• What is the problem?
• What is the solution?
• Technical Direction?
• What is the impact of the solution?

User Story

Short description of the ticket. It should be written in the following format:

As a user, I want to do something, so that I can achieve something.

For example, As a user, I want to login, so that I can access my account.

Acceptance Criteria (AC)

List of conditions that must be met before the ticket can be considered as completed. For example:

• API should return 200 status code.
• API should return the correct data.
• API should return the correct error message.
• API should accept the query parameters correctly and return the correct data.

Status

Current Status of the ticket. It could be To Do, Selected for Development, In Progress, Blocked, In Review, Under Review, QA, Done, etc. These are the standard statuses that are normally set in the project management tool however, it is upto the project manager to set the statuses. Project manager is the one who is responsible to set the statuses and the workflow of the project. Project can add or remove statuses as per the need of the project. But more or less, most the projects have this kind of statuses.

A ticket goes through all these statuses during its lifecycle. For example, when a ticket is created, it is in To Do status. When a developer starts working on the ticket, it is moved to In Progress status. When the developer is blocked on the ticket, it is moved to Blocked status. When the developer completes the ticket, it is moved to In Review status. When the reviewer reviews the ticket, it is moved to Under Review status. When the ticket is under QA, it is moved to QA status. When the ticket is completed, it is moved to Done status.

I have created a table to tell you more about the statuses and their meaning, let's take a look at it:

Status	Description
To Do	When a ticket is created, it is in To Do status.
Selected for Development	When a ticket is selected for development, it is moved to Selected for Development status.
In Progress	When a developer starts working on the ticket, it is moved to In Progress status. It creates branch, do code
Blocked	When the developer is blocked on the ticket, it is moved to Blocked status.
In Review	When the developer completes the ticket, it is moved to In Review status. Push branch, create PR, assign reviewer, etc.
Under Review	When the reviewer reviews the ticket, it is moved to Under Review status. Reviewer reviews the code, and if is good, it merges the PR, and it deploys the code to the staging, and it is moved to QA status. If not, then reviewer comments on the PR, and it is moved back to In Review status.
QA	When the ticket is under QA, it is moved to QA status. QA team tests the ticket and reports if ticket is working or not, if not, then it is moved back to In Progress status, and if yes, then it is moved to Done status.
Done	As ticket is in Done status, it means that the ticket is completed. Now it is ready to be deployed to production.

What can block a ticket?

Ticket can be blocked due to many reasons. For example, frontend is blocked due to API is not available, or waiting for response from client, etc

When ticket is blocked assign the ticket to the person who would clear the blockage. For example, if frontend is blocked due to API is not available, then assign the ticket to the backend developer. When the backend developer clears the blocker, then it will be assigned back to the frontend developer. Make sure to add a comment on the ticket to explain the reason for blocking the ticket so that other people on the team could know, and they can help to unblock the ticket.

Priority

Can be High, Medium, Low, etc. Or it can be any other priority like P0, P1, P2, etc.

It is important to prioritize the tickets because it helps to focus on the most important tickets first. It also helps to avoid the scope creep.

Type

Can be Bug, Feature, Task, Story, etc. It is important to set the type of the ticket because it helps to understand the purpose of the ticket.

• Bug - a bug is a defect in the system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
• Feature - a feature is a new functionality that is added to the system.
• Task - a task is a small piece of work that needs to be done.
• Story - it is a user story that is created to describe the functionality of the system.

note

I mentioned four types of tickets here, but it is not necessary that a project will have all these four types of tickets. Normally, a project will have at least two types of tickets, for example, Bug and Feature. I worked on a project where we had only two type, Task and Story

I told you this as you may wonder what's the difference between Bug, Feature, and Task. Task is basically union of Bug and Feature. So, if you are working on a project where you have only Task type, then consider it is either Bug or Feature depending on the situation.

Difference between a bug and a feature?

Feature means as part of this ticket, we will be adding a new functionality to the system. For example, as part of this ticket, we are adding a new feature to the system that allows users to login to the system.

Bug means we will be fixing a bug (defect) in the system it could be a frontend bug, backend bug, or a database bug. For example, we are fixing a bug in the system that is causing the system to crash when user tries to login to the system with invalid credentials.

Assignee

Person who is assigned to work on the ticket, and assignee is responsible for completing the ticket. Assignee can be a developer, QA, or a business analyst.

For example, business analyst creates a ticket, either he assigns it to any developer or developer self-assigns the ticket, and starts working on it, let's say he faces any blocker, then he will assign the ticket to the person who can help him to clear the blocker, that person will clear the blocker, and then assign the ticket back to the developer. Developer will continue working on the ticket, and when he completes, he pushes the code, creates a PR, and requests for review from the reviewer (can be team lead, or senior developer). Generally, in a project there're more than 1 reviewer, developer will request, and upto reviewer to accept the request, depends on the availablily of reviwer. Once the reviewer accepts the request, then he will review the code, and if he finds any issue, then he will comment on the PR, and if he finds the code is good, then he will merge the PR, and ticket will be assigned to QA, and if they find any issue QA will comment on the ticket, and assign the ticket back to the developer, and if they find the ticket is working as expected, then it will be moved to Done status.

Reporter

Person who created the ticket to report an issue or to request a new feature. Reporter can be a developer, QA, or a business analyst.

Labels

Used to categorize the ticket. For example, bug, feature, task, frontend, backend, database, etc.

Difference between labels and types

Label sounds similar to types, but they are different. Labels are used to categorize the ticket, and types are used to describe the purpose of the ticket.

Sprint

Sprint in which the ticket is created.

Sprint - a sprint is a short, time-boxed period during which a set of work is completed that delivers a potentially releasable product increment.

Epic

An epic is a large user story that can be broken down into smaller user stories. It is used to group tickets together. Normally, an epic is created for a feature.

For example, there is a feature called User Management, and this feature can be broken down into a number of smaller tickets like User Registration, User Login, User Profile, etc. So, we can create an epic called User Management and add all the tickets related to User Management feature to this epic. Epic will help us to track the progress of the feature as we can see all the tickets related to the feature in one place and can see how many tickets are completed, how many are in progress, and how many are left.

Story Points

Story point is a unit of measurement used to estimate the size or complexity of a user story. Normally, it is number between in fibonacci series, for example, 1, 2, 3, 5, 8, 13, 21, etc. And developers give their estimation in story points while planning the sprint, and project manager will decide which tickets will be included in the sprint based on the story points.

Project manager sets the criteria means how many story points one developer to complete in a sprint, normally it is a range, which varies from project to project, and developer to developer. For example, one developer can complete 10 to 15 story points in a sprint, and another developer can complete 20 to 25 story points in a sprint. If a developer is new to the project, then he will be given less story points.

Story points also could be change during the sprint, for example, if a developer finds that the ticket is more complex than he thought, then he will increase the story points, and if he finds that the ticket is less complex than he thought, then he will decrease the story points. But normally decreasing the story points never happens 😉

Attachments

Many people can attach files to the ticket. For example, a developer can attach a screenshot of the bug, or a business analyst can attach a document that describes the feature that needs to be implemented. Attachments can be images, videos, documents, etc.

Linked Issues

Tickets linked to the ticket. It is used to track the progress of the ticket. For example, if a ticket is created to fix a bug, then the ticket will be linked to the ticket that is created to implement the feature that is causing the bug.

Watchers

People who are watching the ticket. They will receive notifications when the ticket is updated. For example, if a developer is assigned to work on a ticket, then he will be added as a watcher to the ticket, and he will receive notifications when the ticket is updated.

Subtasks or child tickets

Subtasks are used to break down a ticket into smaller tasks. For example, if a ticket is created to implement a feature, then the ticket can be broken down into smaller tasks like Create a database table, Create a model, Create a controller, Create a view, etc. And each task can be created as a subtask of the ticket.

But tickets should be as small as possible, creating too many subtasks will make the ticket complex and difficult to track the progress. So, it is not recommended to create too many subtasks but it depends on the complexity and situation.

Linked Branches

Many project management tools also provide a feature to name the branch based on the ticket. For example, if a ticket is created to implement a feature, then the branch name can be feature/feature-name. If a ticket is created to fix a bug, then the branch name can be bug/bug-name, etc. Developer copy the branch name from the ticket and create a branch with the same name, and start working on the ticket. When the developer pushes the code (branch), then the ticket will be updated automatically with the branch name, and the branch name will be linked to the ticket.

So that anyone can see the code related to the ticket.

Linked Commits

Just like branches, commits can also be linked to the ticket. When the developer pushes the code, then the ticket will be updated automatically with the commit hash, and the commit hash will be linked to the ticket.

Linked Pull Requests

Once the developer pushes the code, then he will create a pull request to merge the code into the main branch. And the ticket will be updated automatically with the pull request number, and the pull request number will be linked to the ticket.

Time Estimate

Estimated time required to complete the ticket. Normally, it is written in the following format:

• 1w 2d 4h 30m - 1 week, 2 days, 4 hours, 30 minutes

It is estimated by the developer who is assigned to work on the ticket or by the project manager.

Difference between time estimate and story points

You might be wondering what is the difference between time estimate and story points. Time estimate is the time required to complete the ticket, and story points are the unit of measurement used to estimate the size or complexity of a user story.

Both look similar, but they are different. Time estimate is the time required to complete the ticket, and story points are the unit of measurement used to estimate the size or complexity of a user story. Sounds similar, but they are different.

Created Date

Date on which the ticket is created. It is automatically generated when the ticket is created.

Updated Date

Date when the last update was made to the ticket. It is automatically modified when the ticket is updated.

Comments

Comments are used to discuss the ticket. It is used to ask questions, give suggestions, etc. It is used to communicate with the team members. For example, if a developer is assigned to work on a ticket, then he can ask questions to the project manager or business analyst to understand the ticket better. Comments can be added by anyone who has access to the ticket and can see the ticket.

We can also tag and mention people in the comments. For example, if a developer wants to ask a question to the project manager, then he can tag the project manager in the comment, and the project manager will receive a notification.

You could also message to the person on slack, or discord, whatever communication tool you are using to communicate with the team members but recommended to use the comments because it will be available in the ticket and anyone can see the comments, and it put your questions answers on the record. It has been noticed that people answer faster when they are tagged in the comments than when they are messaged on slack or discord.

History

History is used to track the changes made to the ticket. It is used to track the progress of the ticket. It is used to see who made the changes, when the changes were made, what changes were made, etc. It is used to track the progress of the ticket. It is used to see who made the changes, when the changes were made, what changes were made, etc.

Board

Board is a visual representation of the status of tasks or user stories in a project. Boards are commonly used in Agile methodologies like Scrum and Kanban to track the progress of work and ensure that tasks are moving through the development process efficiently and on schedule, and normally, table shows all the tickets of the current sprint, and their status.

Boards are often displayed on a physical or digital board, allowing all team members to easily see the status of tasks and the progress of the project.

Boards typically consist of columns. Let's see what are columns and how they are used.

Columns

Columns are used to represent the different stages of the development process. For example, To Do, In Progress, Done, etc. Each column can have different types of tickets. For example, To Do column can have Bug, Feature, Task, etc. In Progress column can have Bug, Feature, Task, etc. Done column can have Bug, Feature, Task, etc.

Boards can be customized to fit the specific needs of a project, and may include additional columns or labels to represent different types of work or stages in the development process. Boards are a powerful tool for visualizing work and can help teams to identify and address bottlenecks in the development process.

Summary

In this article, we learned about the project management tools, and we learned about the different features of the project management tools. We learned about the different types of tickets, and we learned about the different fields of the ticket. We learned about the board, and we learned about the different columns of the board. We learned about the different types of columns, and we learned about the different types of tickets that can be created in the board.