Where the work comes from

Code is the last step. Before it, somebody decided what to build, and how that decision is made shapes everything you experience as an engineer.

The two models

Plan driven. Specify everything, then build it. This is correct when the requirements genuinely cannot change: a regulatory deadline, a hardware interface, a contract. It fails when the requirements were a guess, which is most software.

Iterative. Build a small piece, show it, learn, adjust. The bet is that feedback is more reliable than prediction, and it usually is.

What a sprint actually is

Two weeks of work, agreed at the start and reviewed at the end.

planning     what will we do, and is it realistic
daily        what is blocked, not what did you do
review       show working software to whoever asked for it
retrospective what should we change about how we work

The daily meeting is the one most often misused. It is for surfacing blockers so they get resolved today, not for reporting to a manager. A status round where nobody says anything useful is a meeting that should be an update message.

Estimating in points

Teams often size work in relative points rather than hours, and the reason is not mysterious. People are reliably bad at absolute time estimates and reasonably good at comparison: this is about twice that.

After a few iterations the team knows roughly how many points it completes, so forecasting becomes measurement rather than guessing.

It breaks when points are treated as a productivity target. A team asked to increase its velocity will inflate estimates, the number goes up, and nothing changes.

Tickets and scope

A useful ticket says what problem it solves and how you will know it is done. A bad one says "fix the search page".

The practical test: can you name what you will demonstrate, and in under a day? If not, it is several tickets, and splitting before starting costs minutes while splitting on day three costs the three days.

Why you are in these meetings

Engineers frequently see planning as time taken from building. It is where you get to say that the estimate is unrealistic, that the approach will not work, or that there is a simpler version worth 80 percent of the value.

Those points cannot be made later. By then the date is committed and you are the person who has to hit it.