Part 8 — The human requirements › Chapter 47
Agile, tickets and the daily rhythm
Stand-up, sprint, backlog, estimate — what actually happens, and what to say when you are behind.
“Metodologia Agile/Scrum” — which in most Italian software houses means: there is a stand-up, there are tickets, and there is a sprint that sometimes slips. That is the whole of it.
What actually happens
Every morning everyone stands up for ten minutes and says what they did, what they are doing, and what is in the way. Every two weeks the team picks a batch of jobs and tries to finish them. That is it. The books are long; the practice is short.
| Ritual | Nominally | In practice |
|---|---|---|
| Daily stand-up | 15 min: yesterday, today, blockers | Often 25. Keep your part to two sentences and it will be noticed |
| Sprint planning | Choose and size the work | Where you find out what you have committed to |
| Refinement / grooming | Clarify upcoming tickets | The most valuable meeting for you. Ask the data questions here |
| Review / demo | Show the increment | Show the report, not the query |
| Retrospective | Improve the process | Bring one concrete thing, not a complaint |
Everyone else is discussing the screen. You are the one who asks “what happens to the existing rows?”, “is that unique per customer or globally?”, “does this need to be true historically, or only from now on?”. Those three questions, asked before the work starts, prevent more rework than anything you can do afterwards — and asking them is how a junior becomes the person whose opinion is sought.
The stand-up, in two sentences
Too much detail: three minutes on the join you fixed. Nobody can use that information. Too little: “still on the same ticket”, three days running, with no signal. The second is worse, because it looks like either hiding or drifting.
“Yesterday I finished the reconciliation query for ticket 412 — the difference was cancelled orders being counted in one report and not the other. Today I am on 415, the slow warehouse screen. No blockers.” — Outcome, cause, next, blocker. Twelve seconds.
When you are behind
Say it early, say it specifically, and bring an option. A slip announced on day two is a planning adjustment. The same slip announced on the last day is a broken promise — identical work, completely different consequence. Nobody is angry that estimating is hard; people are angry about being told late.
Not: "It's taking longer than expected."
Not: "Almost done." ← the most expensive two words in software
But: "415 will not be ready by Thursday. The report is slow because
the underlying view joins two child tables and fans out, so the
fix is restructuring it rather than adding an index.
I need about two more days.
If Thursday is fixed, I can ship a version limited to one region
and finish the rest next sprint. Which would you prefer?"
- The fact, first and unhedged. “Will not be ready by Thursday” before any explanation, because that is the only part your manager needs in order to act.
- The technical reason, in one sentence a non-specialist can follow. It shows the delay is understood rather than mysterious — the difference between a problem and a worry.
- A new estimate. Nobody is angry that estimating is hard; people are angry about being told late.
- An option, and a question. You are handing back a decision that is genuinely theirs, with the trade-off already worked out. That is what “senior” sounds like, at any level of seniority.
Note the structure: what will not happen, why, technically and briefly, the new estimate, an option they can choose. It converts your problem into their decision, which is exactly what a manager wants.
Estimating, when you cannot know
- The data is unknown until you look. "Add a unique constraint on email" is ten minutes — unless there are 4 000 duplicates, and then it is a week of deciding which row wins and who to tell.
- Production behaviour differs from test. A migration that takes 40 ms on 200 rows may take eleven minutes on 200 million, and you will not find out on your laptop.
- Estimate the investigation separately. “Half a day to find out how many duplicates there are, then I can estimate the fix.” That is a real, deliverable, honest unit of work — a spike — and asking for one is normal, not an admission.
- Give a range with the reason. “Two days if the data is clean, a week if it is not, and I will know which by tomorrow afternoon.” Ranges are more useful than a single number everybody knows is fiction.
Tickets, and leaving a trail
When you discover why the report was wrong, put it in the ticket: the query that proves it, the number before and after, and the cause in one sentence. Six months later somebody — quite possibly you — will search for that. A chat message is gone; a ticket comment is institutional memory, and being the person who leaves one is disproportionately valued.
| Italian | Means |
|---|---|
| presa in carico | Taken on / assigned to me. What you say when you start a ticket |
| in lavorazione | In progress |
| collaudo | Acceptance testing — usually by the client or an analyst |
| avvio in produzione / messa in produzione | Go-live |
| rilascio | Release / deploy |
| segnalazione | A reported issue, from a client |
| capitolato | The specification document, usually contractual |
| fermo / bloccante | Blocked / blocking |
The rhythm that actually matters
- Finish things. Three tickets done beats six at 80%. Work in progress helps nobody and hides risk.
- Ask early, not at hour six. Twenty minutes stuck is thinking; three hours stuck is a decision to waste an afternoon. See chapter 48 for how to ask well.
- Leave the campsite tidier. Name the constraint you added, comment the non-obvious query, write the finding in the ticket.
- Do not be surprising. Predictable is a compliment. Being the person whose estimates can be planned around is worth more than being the fastest.
- Agile in practice is a stand-up, tickets and a sprint. Do not over-prepare for the theory.
- Refinement is where a database person earns their reputation: ask the data questions before the work starts.
- Stand-up is two sentences: outcome, cause, next, blocker.
- “Almost done” is the most expensive phrase in software.
- Announce a slip early, with a reason and an option. It converts your problem into their decision.
- Estimate the investigation separately when the data is unknown. A spike is a legitimate unit of work.
- Give a range with a reason rather than a number everyone knows is fiction.
- Write findings in the ticket, not in chat. It is institutional memory.
- Finish things. Three done beats six at eighty per cent.
- Predictable is a compliment.
Interview questions this chapter answers
Have you worked in an Agile team?
Describe the rhythm rather than the vocabulary: a daily stand-up, two-week sprints, refinement before the work starts, a demo at the end. Then say what you personally did in it — “in refinement I would ask what happens to existing rows and whether a value is unique per customer or globally, because those are the questions that cause rework if nobody asks them.”
What do you do when you realise you will miss a deadline?
Say so as soon as I know, with the specific reason, a revised estimate, and an option — usually a reduced scope that still ships on the original date. The cost of a slip is mostly in how late it is communicated; the same delay announced on day two is a planning adjustment.
How do you estimate work when you do not know the data?
I separate the investigation from the fix and estimate them separately — half a day to find out how bad the duplicates are, then a real estimate. If pressed for a single number I give a range with the reason for the spread and say when I will be able to narrow it.