What is the difference between Scrum Master and Technical Project Mananger?

Aspect	Scrum Master	Technical Project Manager (TPM)
Primary Focus	Facilitating Agile processes and team dynamics	Delivering projects with technical scope, timelines, and resources
Key Goal	Empower the Scrum Team to be self-organizing and high-performing	Ensure successful delivery of technical projects
Ownership	Process & team effectiveness	Scope, schedule, budget, and technical execution
Typical Tasks	- Facilitate stand-ups, retrospectives, sprint planning - Remove blockers - Coach Agile principles - Promote team collaboration	- Manage timelines & deliverables - Work with engineering leads on system design - Coordinate cross-team dependencies - Report progress to stakeholders
Technical Involvement	Low to moderate (depends on background)	High – often understands architecture, APIs, infrastructure, etc.
Stakeholder Interaction	Primarily with the dev team and Product Owner	Frequent updates to business stakeholders, clients, and execs
Reporting Lines	Often reports to Agile Coach or Program Manager	Reports to Engineering Manager, PMO, or senior leadership
Mindset	Servant-leader, facilitator	Project leader, delivery-focused

🔑 Summary

• A Scrum Master ensures the Agile process runs smoothly and the team stays focused, collaborative, and empowered.
• A Technical Project Manager ensures the project gets delivered on time, within scope, and often bridges technical and business teams.

🧠 Think of it this way: The Scrum Master is a team coach, while the TPM is a project owner/driver with technical fluency.

How would you handle conflict within the team?

 

1. 🧘 Stay Neutral and Calm

• Avoid taking sides.

• Keep your tone calm and non-defensive.

• Set a tone of respect and professionalism.

“Let’s take a moment to understand each other’s perspectives without judgment.”

---

2. 🎧 Listen Actively to All Parties

• Give each person a chance to speak without interruption.

• Show that you're listening: summarize, clarify, and ask open questions.

“What I’m hearing is that you’re concerned about deadlines, while your teammate is focused on quality. Is that correct?”

---

3. 🔍 Identify the Root Cause

• Conflicts often stem from:

  • Miscommunication

  • Conflicting priorities

  • Ambiguous roles

  • Personality clashes

Try to dig beneath the surface to find the real issue.

---

4. 🤝 Encourage Open Communication

• Create a safe space for everyone to express concerns.

• Reinforce psychological safety—no one should fear backlash for speaking up.

“Let’s use ‘I’ statements and focus on behaviors, not personal attacks.”

---

5. 📄 Clarify Roles and Expectations

• Often, conflict arises from unclear ownership.

• Clarify responsibilities, deliverables, and expectations.

“Let’s define who owns what so that we can avoid overlap or misunderstandings.”

---

6. 🛠️ Facilitate a Resolution Together

• Encourage the team to propose solutions.

• Aim for win-win compromises.

• If needed, involve a Scrum Master, HR, or mediator.

“What solution would work for both of you and help us move forward?”

---

7. 📅 Follow Up

• Don’t assume it's resolved forever.

• Check in later to ensure things have improved and trust is being rebuilt.

“How are things going now? Anything lingering that we need to address?”

---

8. Use Agile Ceremonies:

• Retrospectives are a great way to surface tensions safely.

• Use techniques like:

• Start/Stop/Continue

• Sailboat method

• ROTI (Return on Time Invested)

🗂️ Team Conflict Resolution Template

💬 Goal: Facilitate a respectful discussion and guide the team to a resolution.

🧘 1. Set the Stage (5 mins)

Say:

“Thanks for joining. I know there’s been some tension, and I want us to resolve this constructively. This is a safe space to speak openly. Let’s stick to facts, not assumptions, and focus on solutions.”

Tips:

• Establish ground rules: one person speaks at a time, no interrupting, stay respectful.

• Offer a neutral tone and setting (not in front of the whole team).

---

🎧 2. Listen to Each Party (10–15 mins)

Take turns asking each person:

Prompt:

“Can you help me understand your perspective on the issue?”

Use active listening:

• Reflect back: “So you’re feeling [emotion] because [reason]—is that right?”

• Clarify misunderstandings.

---

🔍 3. Identify the Root Cause (5–10 mins)

Ask:

“What do you think is the underlying issue here?”

Common causes:

• Role ambiguity

• Communication gaps

• Differences in values (speed vs. quality, etc.)

• Workload imbalances

Summarize what you’ve heard:

“It seems like the main issues are [X] and [Y]. Do we all agree on that?”

---

⚖️ 4. Co-Create Solutions (10–15 mins)

Ask:

“What changes would help us work better together moving forward?”

Encourage them to suggest:

• Role clarifications

• New communication norms

• Adjustments to workload or process

Then agree on concrete actions:

“Let’s agree on [solution]. Who will do what, and by when?”

---

📅 5. Follow Up and Monitor (After 1–2 weeks)

Say:

“Let’s check in next week to make sure things are improving. Feel free to reach out before then if needed.”

---

 

How user story estimation is done in agile scrum project?

 In Agile Scrum, user story estimation is the process of assessing the effort required to implement a user story. The goal is to help the team understand the relative complexity, risk, and size of each task so they can plan and prioritize effectively.

---

🛠️ Common Estimation Techniques

1. Story Points (most common)

• A relative measure of effort (not tied to hours or days).

• Typically use a Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) to reflect increasing uncertainty as complexity grows.

• Factors considered: complexity, risk, unknowns, amount of work.

2. Planning Poker

• Team members estimate a story by playing cards with point values.

• Everyone reveals their card at once, then discuss differences.

• Repeated until consensus is reached.

3. T-shirt Sizes

• Use sizes like XS, S, M, L, XL to indicate rough sizing.

• Often used in early backlog grooming or with non-technical stakeholders.

4. Bucket System

• Stories are sorted into "buckets" of effort (e.g., 1, 2, 3, 5, 8 points) through collaborative team discussion.

---

📦 Example User Story:

“As a user, I want to reset my password so that I can regain access if I forget it.”

Team might discuss:

• Is it a standard workflow?

• Any third-party integration (e.g., email)?

• Edge cases (token expiration, security)?

• Level of test coverage needed?

After discussion, team agrees it’s a 5-point story.

---

✅ Best Practices

• Estimate as a team, not individually.

• Keep estimates relative (compare stories against each other).

• Don’t equate story points directly to hours.

• Re-estimate if requirements change significantly.