Feature Iteration
Last updated
Last updated
Each feature iteration has a title, a consecutive Roman numeral, and stages controlled by the Iteration Lead responsible for its delivery. It also includes the lead's lane, other developers' lanes, and a technical damage list (if any is reported). Currently, there are no restrictions on the developers' lanes — you can choose the genre and content style.
However, we encourage you to avoid using "Given-When-Then" acceptance criteria and instead use plain narrative for requirements. If you're using external resources like OpenAPI tools (Swagger, etc.) or design tools (Figma), we strongly recommend documenting only information and requirements that cannot be directly derived from those resources. Otherwise, inevitable changes in those resources will render the feature iteration content outdated and require maintenance. For all requirements, having single source of truth is critical. Use Occam's razor.
Forming and writing up the developer lane is not the responsibility of the product manager or business analyst only. While a business analyst can provide product requirements, the feature iteration exists to make product maintenance and future development easier for your future self and your teammates. Developers control their lanes, and we encourage them to include technical details about trade-offs, tricky fixes, and solutionts they are proud of — everything that usually goes into PR descriptions, and more, because it covers the entire feature iteration assigned to the developer.
The developer lane is not just a write-up of technical requirements; it's a living document resulting from collaboration between product and engineering. It reflects not only what is expected but also documents the technical implementation process and its outcome.
With Swinlanes, the usual Agile question — "Should that be another ticket?" — simply doesn't exist. It just goes into the developer lanes. How to break down a feature iteration into lanes is a decision handled by the Iteration Lead.
