By Veenu Singh, Founder & CEO, TrackPM · Last updated: September 2026 · 8 min read

A Scrum board is a visual project management tool that shows every task in a sprint, who owns it, and what stage it is in — all in one shared view. For Indian IT startups running agile delivery for software products or client projects, a Scrum board replaces the status meeting, the "can you send me an update?" Slack message, and the end-of-sprint "what actually got done?" confusion.

According to the 2026 Agile Trends Report, more than 71% of digital product teams globally use Scrum or Scrum-inspired frameworks. Indian IT teams are increasingly the same — but most set up their Scrum boards incorrectly at first, use tools that are too complex for their team size, or abandon the process within two sprints because the overhead feels greater than the benefit.

This guide covers exactly how to set up a Scrum board that your Indian IT team will actually use — the right columns, the right sprint length, how to run sprint planning, and the five mistakes that derail most first attempts.

What Is a Scrum Board — and How Is It Different from a Kanban Board?

Both Scrum boards and Kanban boards are visual project management tools. The key difference is time-boxing.

A Kanban board is continuous — tasks move through columns (To Do → In Progress → Done) with no time limit. It suits teams managing ongoing support, maintenance, or operations work where priorities change daily.

A Scrum board is sprint-based — at the start of each sprint (typically 1–2 weeks), the team commits to a specific set of tasks from the backlog. Those tasks go on the board. At the end of the sprint, the board resets. The key discipline is the commitment — once tasks are in a sprint, the team does not add new work mid-sprint without removing something else.

For Indian IT startups doing product development or client project delivery — Scrum is the better fit. The fixed sprint cycle creates predictable delivery cadences, makes client commitments manageable, and gives founders and team leads a clear view of progress without daily status calls.

TrackPM includes both Scrum boards and Kanban boards — teams can use whichever fits the project, or run both simultaneously across different workstreams.

The 4 Scrum Roles — Simplified for Indian IT Startups

Full Scrum methodology defines three formal roles: Product Owner, Scrum Master, and Developers. For a 5–20 person Indian IT startup, strict role separation is often impractical. Here is how these roles typically work in practice:

• Product Owner (PO) — The person who defines what gets built and in what priority order. In most Indian IT startups, this is the founder, the CTO, or the client-facing project manager. Their job is to maintain a prioritised backlog — a ranked list of everything the team could build next — and to clarify requirements when the development team has questions.
• Scrum Master (SM) — In small teams, the Scrum Master role is usually combined with the team lead or project manager role. The SM's job is to run sprint ceremonies (planning, standup, review, retrospective), remove blockers, and protect the team from mid-sprint scope changes. In a 10-person Indian IT team, this takes approximately 3–4 hours per week, not a full-time role.
• Developers — Everyone doing the work: developers, designers, QA testers, DevOps engineers. In Scrum, "developers" means anyone contributing to deliverables, not just programmers.

Practical shortcut for small Indian IT startups: The founder or CTO acts as Product Owner. The most senior engineer or team lead acts as Scrum Master. Everyone else is a developer. This works fine for teams of 5–20 people. Add more role specialisation as the team grows past 25.

Step-by-Step: How to Set Up Your Scrum Board

Step 1 — Set Your Sprint Length (choose before anything else)

Sprint length should be decided before you create the board. The options are:

• 1-week sprints: Suit fast-moving client projects with frequent feedback cycles. High ceremony overhead relative to delivery time — works best when tasks are small and well-defined.
• 2-week sprints: The most common choice for Indian IT startups. Enough time to deliver meaningful features without losing momentum. Recommended for most teams of 5–20 people.
• 3–4 week sprints: Better for complex product development where tasks require sustained focus. Risks: team direction drift, and sprint reviews become high-stakes.

For most Indian IT startups: start with 2-week sprints. You can always adjust after the first three sprints once you understand your team's velocity.

Step 2 — Create Your Board Columns

A Scrum board for a small Indian IT team needs exactly these columns — no more:

The "Blocked" column is non-negotiable. Most Scrum board templates skip it. For Indian IT teams — where blockers often involve client approvals, third-party API dependencies, or waiting for assets from a design team — having a visible Blocked column means blockers are surfaced immediately rather than discovered at the sprint review when it is too late.

Step 3 — Build Your Product Backlog Before Sprint 1

A Scrum board only works if there is a prioritised backlog to pull from. Before your first sprint, spend 2–3 hours with the Product Owner building the backlog:

• Write every feature, bug fix, improvement, and task as a separate card
• Write each card as a user story: "As a [user], I want to [action] so that [benefit]" — or for IT service teams, simply as a clear task description with acceptance criteria
• Rank them from highest to lowest priority
• The top 20–30 tasks should be detailed enough that a developer can start them without asking clarifying questions
• Everything below rank 30 can be rough — it will be refined before it enters a sprint

Backlog refinement tip for Indian IT teams: Run a 30-minute backlog refinement session every Thursday — the week before your Monday sprint planning. The PO reviews the top 10 upcoming items, developers flag questions or ambiguities, and any unclear items are broken down further. This prevents sprint planning from turning into a requirements session, which is one of the most common reasons sprint planning runs for 3 hours instead of 45 minutes.

Step 4 — Run Sprint Planning (45 minutes, not 3 hours)

Sprint planning is the ceremony where the team selects tasks from the backlog and commits to delivering them in the upcoming sprint. For a 2-week sprint with a team of 8–12 people, this should take 45–60 minutes if the backlog is well-prepared.

The agenda:

• 10 minutes — Sprint Goal: The Product Owner presents the sprint goal — one sentence describing what the team is trying to achieve this sprint. "Complete the client onboarding flow and fix the three critical bugs from last sprint's review." Everyone agrees or raises concerns before any tasks are discussed.
• 20 minutes — Task selection: The team pulls tasks from the backlog into the sprint. Developers self-assign based on their expertise and available capacity. Calculate capacity first: a 2-week sprint has 10 working days × number of developers × 6 productive hours per day (not 8 — meetings, email, and context-switching consume the rest). Do not commit to more than 70–80% of total capacity.
• 15 minutes — Task breakdown: Any task estimated at more than 3 days of work gets broken down into smaller sub-tasks. A task that takes more than 3 days is usually not well-defined enough to track progress daily. Break it down until each sub-task can be completed in 1–2 days.
• 5 minutes — Confirm and close: The Scrum Master reads back the sprint commitment — sprint goal, list of tasks, and total estimated days. Everyone confirms. The board is updated. Planning is done.

Step 5 — Run Daily Standups in 15 Minutes

The daily standup is a 15-minute sync, not a status report. Three questions per person:

• What did I complete yesterday?
• What will I do today?
• Is anything blocking me?

Answers should be 30 seconds per person. Blockers are the only item that gets a follow-up discussion — and that discussion happens after the standup, not during it, and only with the people relevant to the blocker.

For distributed Indian IT teams (developers in Bengaluru, designers in Pune, QA in Hyderabad): async standups work well. Each team member posts their three-line update in a dedicated Slack channel or team chat by 10 AM. The Scrum Master reviews Blocked items by 10:30 AM and takes action. This eliminates the timezone and meeting-fatigue overhead of a daily video call.

Step 6 — Sprint Review + Retrospective (Last Day of Sprint)

Sprint Review (30 minutes): The team demonstrates what was completed to the Product Owner (and optionally to stakeholders or clients). What is done gets marked Done. What is not done goes back to the backlog for re-prioritisation — it does not automatically roll into the next sprint.

Retrospective (30 minutes): Three questions:

• What worked well this sprint?
• What did not work?
• What will we change in the next sprint?

Write the answers. The Scrum Master follows up in the next retrospective to check whether the agreed changes actually happened. A retrospective where action items are never reviewed is a retrospective that erodes trust in the process.

5 Mistakes Indian IT Startups Make with Scrum Boards

• 1. Adding tasks mid-sprint without removing others. "One quick thing" mid-sprint is the most common reason sprint commitments are missed. Establish a firm rule: new work in = equal work out, or it goes to the backlog for the next sprint. The only exception is a production emergency.
• 2. Too many tasks in "In Progress" simultaneously. A developer with 5 tasks In Progress is not working on 5 things — they are switching between them and completing none efficiently. Enforce the WIP limit of 2 tasks per developer In Progress at any time. The constraint feels uncomfortable at first and dramatically improves throughput.
• 3. Skipping the Blocked column. When blocked tasks stay "In Progress", managers cannot see them. Create the Blocked column, move tasks there immediately when they stall, and review it every morning. A task that is blocked for 3 days needs escalation — not silence.
• 4. Running sprint planning without a prepared backlog. Spending sprint planning writing requirements from scratch is the most common reason it takes 3 hours. Backlog refinement (30 min on the Thursday before) prevents this entirely.
• 5. Not adjusting sprint length after the first three sprints. Your initial sprint length is a hypothesis. After three sprints, check: are you consistently completing all sprint tasks (sprints are too short — extend), or are you consistently leaving 40% incomplete (sprints are too long or team is over-committing — shorten or reduce load). Adjust based on real velocity data, not gut feeling.

How TrackPM's Scrum Board Works for Indian IT Teams

TrackPM's project management software includes Scrum boards built specifically for Indian IT teams — with sprint planning, backlog management, task assignment, WIP limits, a dedicated Blocked column, and sprint velocity reporting.

The key differentiator for Indian IT companies: TrackPM connects the Scrum board directly to time tracking and attendance. When a developer is on approved leave during a sprint, their capacity is automatically reflected in the sprint planning view — so you do not plan a 10-day sprint for a developer who is available for 7. When a sprint ends, the time logs show exactly how many hours each task consumed — useful for client billing and for calibrating future sprint estimates.

Setup takes under 30 minutes. First sprint can start the same day.

Frequently Asked Questions

What is the best Scrum board software for Indian IT startups in 2026?

For Indian IT startups needing Scrum boards alongside time tracking, attendance, and payroll in one platform, TrackPM is the most integrated option at INR pricing. For project management only, Jira is the global standard but adds complexity and USD pricing. Linear is popular among early-stage product teams for its speed. For teams that only need a simple visual board without HR or time tracking integration, Trello or Notion boards work well. The best tool is the one your team actually uses consistently — start simple and add complexity only when the team outgrows the simpler tool.

How long should a sprint be for a 10-person Indian IT startup?

Two weeks is the recommended starting sprint length for most Indian IT startups with 8–15 developers. One week provides fast feedback but high ceremony overhead relative to delivery time. Two weeks balances delivery cadence with planning efficiency. Start at two weeks and adjust after three sprints based on your team's actual velocity and completion rate.

How many tasks should be in a sprint for a small Indian IT team?

Calculate capacity: number of developers × working days in sprint × 6 productive hours per day. Then plan for 70–80% of that capacity — not 100%. Over-committing is the most common sprint failure pattern. For a 5-developer team on a 2-week sprint: 5 × 10 × 6 = 300 hours capacity × 75% = 225 hours of committed work. Break that into tasks where each task is 1–3 days — approximately 15–25 tasks total for the team.

Can a Scrum board work for remote Indian IT teams across multiple cities?

Yes. Remote Scrum works well when two conditions are met: a shared digital board that all team members can access and update in real time (not a physical whiteboard in one office), and async standups replacing daily video calls. Indian IT teams with developers in Bengaluru, Pune, Hyderabad, and Delhi find async standups — three-line updates in a shared chat by 10 AM — more sustainable than a daily video call across time zones and laptop setups.

How is Scrum different from Kanban for Indian IT companies?

Scrum uses fixed-length sprints (typically 2 weeks) where the team commits to a specific set of tasks at sprint start and does not change scope mid-sprint. It suits product development and client delivery projects with defined phases. Kanban has no fixed sprint cycles — tasks flow continuously, priorities shift daily, and there is no sprint commitment. It suits support, operations, and maintenance work where incoming work is unpredictable. Many Indian IT companies run Scrum for their product development teams and Kanban for their support and DevOps teams simultaneously, using a platform like TrackPM that supports both.

Conclusion

A Scrum board only earns its keep when the sprint length matches your team's rhythm, the backlog is ready before planning starts, and blockers are visible the moment they happen — not discovered at the review. Get those three things right and the ceremonies stop feeling like overhead. TrackPM brings Scrum boards together with time tracking, attendance, and project management on one platform built for Indian IT teams.