Time Estimation and Scrum Ceremonies

"How long will this take?" is the question that has derailed more software projects than any bug ever could. This lesson is about how modern teams answer it — and the rituals they've built to stay synchronised while doing it.

Learning Objectives

By the end of this lesson you will be able to:

• Explain why teams use Story Points instead of hours for estimation
• Describe the purpose of Sprint Planning, the Daily Standup, and the Sprint Retrospective
• State clearly what a QA engineer is expected to contribute at each ceremony

Story Points: Estimating Complexity, Not Time

Story Points are a relative measure of the effort, complexity, and uncertainty involved in completing a task — not the number of hours it will take.

Why not just use hours?

Hours are an illusion. The same task takes 2 hours for a senior developer and 8 hours for a junior one. It takes 1 hour on a Monday and 4 hours on a Friday before a release. Hours invite false precision.

Story Points say: "Relative to ticket X (which we all agreed is a 3), this ticket feels like a 5."

Common Story Point scales:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21 (gaps get bigger as complexity increases)
• T-shirt sizes: XS, S, M, L, XL

How estimation happens: Teams use Planning Poker — each person simultaneously reveals their estimate for a ticket. If estimates differ widely, the team discusses why. This surfaces hidden complexity before development begins.

QA's role in estimation: You estimate the testing effort, not just the development effort. A "2-point" feature might be an "8-point" testing job if it touches authentication, payments, and mobile. Speak up — your estimate matters.

The Sprint

In Scrum, work is organised into Sprints — time-boxed iterations of 1–4 weeks (most commonly 2 weeks). At the end of every sprint, the team should have delivered working, tested software.

The sprint cycle:

Sprint Planning → Daily Work (Standups) → Sprint Review → Retrospective → (next sprint)

Sprint Planning — The Sprint's Foundation

What: The team selects tickets from the backlog to work on during the sprint, estimates them, and commits to a sprint goal.

When: First day of the sprint, typically 1–2 hours.

QA's contribution:

• Raise questions about unclear Acceptance Criteria before picking up tickets
• Flag if testing capacity is insufficient for the planned scope ("We have 8 tickets; I can test 5 in this sprint — we need to descope or add capacity")
• Ask about dependencies: "If ticket B depends on ticket A, which one gets tested first?"

Daily Standup — 15 Minutes That Run the Day

The Daily Standup (or Daily Scrum) is a 15-minute synchronisation meeting. Each team member answers three questions:

1. What did I work on yesterday?
2. What will I work on today?
3. Do I have any blockers?

That's it. It is not a progress report to management. It is not a problem-solving session. It is a quick sync so everyone knows the state of the sprint.

What a QA engineer says:

Yesterday: "I tested the password reset flow — 3 out of 4 ACs passed.
            I opened bug BUG-447 for the email template rendering issue."

Today:     "I'll finish the password reset ticket and pick up the 
            notification preferences feature."

Blockers:  "I'm waiting on a staging environment fix from DevOps —
            the email service isn't sending on staging."

Common mistake: New QA engineers either say nothing ("all good") or turn the standup into a testing monologue. Keep it to three answers, one minute, and surface blockers early.

Sprint Review (Demo) — Show the Work

What: The team demonstrates completed features to stakeholders (PO, PM, sometimes real users).

When: Last day of the sprint, 30–60 minutes.

QA's role: You've already signed off on everything that gets demoed. If a bug surfaces during the demo that you missed — own it, create a ticket, and commit to finding the root cause in the retrospective.

Sprint Retrospective — Make the Next Sprint Better

What: The team reflects on the process (not the product) and identifies concrete improvements.

When: End of sprint, 45–90 minutes.

Three questions:

1. What went well?
2. What didn't go well?
3. What will we change next sprint?

QA's contribution to retros:

• "We had 3 regression bugs from tickets that were tested in isolation. Proposal: add a cross-feature smoke test to our DoD."
• "I was only looped in on 2 out of 8 tickets during refinement. I'd like to be included in all refinement sessions going forward."

The Retrospective is one of the most powerful tools in a team's toolkit — use it.

Summary

You now understand the full lifecycle of a task and the team rituals that keep it on track. Module 3 zooms out to the entire Software Development Life Cycle.