There’s a lot to unpack when working with an agile agency or advocating for agile at your own company. To an untrained eye, agile ceremonies might look like an overhead. Two of them – review and retrospective – have synonymous names. It doesn’t help your case.
If you had to differentiate between agility and “Agile” (with a capital “A”), how would you explain the difference?
Agile is a peculiar methodology. It’s scary to trust the process when you have to jump into your first project without a fixed budget. But Agile isn’t devoid of estimates.
There’s one particular principle in the Agile Manifesto that makes eyebrows rise when you hear “agile” and “planning” in the same sentence. Agile is all about continuous improvement and delivery. It values communication over documentation and tackles issues “as and when needed”. Is there a place for planning in such an environment?
In agile, velocity is a concept which refers to the amount of work that has been done during an iteration. It’s a measurement that tracks information about work completed, work started, and work remaining. Velocity is considered to be one of the most important metrics in agile. Not only does it allow you to track progress, but it also helps deliver the most value.
What is a user story? Why write it? Who writes? What is a good example of a user story? Are there any exceptions? In this article, I focus on an in-depth analysis of writing user stories from different angles.