Angelica
All notes
03

Learning in public

5 min read

What my Scrum board taught me

On Agile, SDLC process models, and CI/CD, and what actually connects a backlog to a live deployment.

This term I built a Scrum board for a small task manager app, and it made something click that the lecture slides alone had not. Agile is usually described as a mindset. Setting up the board made it clear that mindset only works if the requirements underneath it are precise. An Epic is the whole book. A Story is one chapter. A Sub-task is a paragraph inside that chapter. Deciding what belongs at which level is not organising, it is scoping, and scoping badly means a two-week sprint quietly becomes a four-week one.

Before this unit I thought of Agile and Waterfall as opposites. They are not. Both are answers to the same question: how much change can the plan absorb once work has started? Waterfall answers "very little" and locks requirements before development begins. Agile answers "constantly" and plans in small enough increments that change stays cheap. Most real systems mix both, plan-driven where requirements are stable, agile where they are not.

The same rethink happened with deployment. I used to say "CI/CD" as one term. They are three different guarantees. Continuous Integration means code gets merged and tested constantly. Continuous Delivery means the software stays in a deployable state, but a person still decides when it actually ships. Continuous Deployment removes that person entirely, the pipeline decides. That single missing approval step is the real difference between a team that could deploy today and a team that does deploy today, automatically, every time a test suite passes.

What connects the Agile side to the deployment side is one continuous loop, not two separate stages. A sub-task from a sprint becomes code. Code becomes a build. A build gets tested. A tested build gets released. A release gets deployed. A deployed system gets monitored. What monitoring finds goes straight back into the backlog. Waterfall draws the lifecycle as a line with an end point. This loop has no end point.

None of this looked obvious from the slides. It looked obvious once I had to decide, for my own project, whether something was a Story or a Task, and once I understood that "we do CD" is not one sentence, it is three different claims. The frameworks in this unit are not abstract diagrams. They are the actual shape of the decisions I made setting up one small Scrum board.