Some time ago, in a discussion about incrementing versions in CI builds, I suggested that a release version should be defined by a Product Owner and should not be incremented in CI builds, and that a build number should be used instead to track packages produced by CI pipelines.

One of the participants commented that I must be working in a corporate environment and that most Open Source projects do not have a Product Owner and build numbers are not something that a small team would use. This point of view is incredibly misguided, but it is also, unfortunately, quite widespread.

Requirements remind me one of The Simpsons episodes, where Bart reads outs loud junk mail: "Gas your termites. Freeze your termites. Zap your termites. Save your termites?" and it feels sometimes that writing good requirements is more of an art form than a teachable skill.

In the world of agile development, requirements are often seen as something cavemen used to gather, but in reality user stories serve the exact same purpose as requirements, with the intent to avoid the black magic that requirements are made of.

This post describes some of the practical usefulness in well written requirements that I found for myself and how requirements can make managing projects a bit more straightforward.

How many times you heard in agile planning meetings that a similar user story has been done before, so the user story in question can benefit from that experience and can be assigned a fraction of the original story point value? If the answer is more than once, chances are, your planning meeting are long and contentious and past velocity rarely comes up when you are filling up the next sprint.