# On Agile In 2001, seventeen software developers met at a resort in Utah, United States, to discuss various lightweight development methods. The document they created during that retreat became known as the Manifesto for Agile Software Development. It was a collective effort to unify methodologies and push back against the heavyweight, micromanaged, and overly regulated approaches commonly referred to as Waterfall. The Manifesto contains 12 principles, but only four 'values' are widely remembered: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan These principles set the tone for Agile, branding it as a new, more efficient, and progressive approach compared to the “old way.” Unfortunately, in practice, the principles turned out to be too vague to apply directly to software development. Even after more than 20 years, people still debate what Agile truly is — a philosophy, methodology, framework, or set of values? Countless books have been written to clarify it, and thousands have been certified as Agile practitioners and Scrum Masters to teach others how to “do Agile” correctly. And if Agile doesn’t work for you, you ain't doing it right, for sure. Yet, despite years of widespread use, there’s no clear evidence that Agile truly works. It became the default simply because Waterfall — the “plan-everything-then-build-everything” approach — only works when you know exactly what to build in advance. In startups, where you’re creating something new, that’s rarely possible. Also, in a single-product organizations, developers can’t sit idle while waiting for product managers and designers to create all the specifications. ### Rolling Downhill on a Kanban Board Two years later, in 2003, Mary and Tom Poppendieck published the now-classic book *Lean Software Development: An Agile Toolkit*. It was the first attempt to adapt methods used in Japanese Toyota plants to software development. Judging by the fact that most developers worldwide now drag tickets across Kanban boards, that attempt was successful. But was it really, and for whom? It’s unclear why Mary and Tom thought it would work for software. Toyota used Kanban boards to produce identical cars from identical physical parts. An assembly line might have 300 to 500 stations, each with workers performing one specific, clearly defined operation. Once the car leaves the factory, it’s no longer the assembly line workers’ responsibility; they just move on to the next one. The assembly line is transactional, with each completed car as the final product, and many operations are independent of one another. For example, the team painting the car doesn’t need to worry about the station installing the audio system, and the tire installation doesn’t depend on the quality of the seat installation. None of this is true for software development. It’s not transactional because new code is built on top of existing code, layer by layer, constantly evolving. Poor decisions made by previous developers affect everything you can and cannot do easily with the codebase. Software development is more like building an ever-growing skyscraper or cultivating a tree. ### Code Ownership vs. Ticket Mentality When a car leaves the factory, repair shops handle broken lights or squeaky wheels — not the assembly line workers. Similarly, once a ticket reaches its “Definition of Done,” it disappears into the void. You’ll be lucky if your Kanban board tool has decent search functionality to help you find that ticket later. It will be much harder for your successors. But even if they do find it, how can they tell if the information is still relevant or hasn’t been overwritten by another ticket? With a Kanban board, developers have little direct incentive to care beyond their immediate tasks. Found a bug after deployment? Great, that’s just another ticket — a new way to show productivity to the manager. Missed a requirement? Another task or maybe user story with story points attached. Developers who churn out low-quality code quickly often win in Agile, while their teammates are left to fix bugs and refactor code later at their own expense. The link between bugs and hasty delivery is largely overlooked. “If it’s not in Jira, it never happened.” This ticket mentality does not incentivise code quality or long-term thinking. It prioritises velocity and burndown charts, which are rarely satisfactory. Non-technical people cannot gauge code quality or overall codebase degradation until it’s too late. As a result, costly rewrites are still common in the industry. Technical leaders often speak about code ownership, but what they’re really trying to address is widespread ignorance. Many developers don’t look beyond poorly written user stories and don’t face the consequences of their mistakes unless it’s a critical issue for a major user. They’re paid to fix their own errors without truly learning from them. On the other hand, capable developers are forced to cut corners during the typical end-of-sprint rush, which often leads to growing frustration and burnout. This is how Agile, along with its main visual embodiment — the Kanban board — have failed software development. Agile attempted to merge heuristics with programming and it was a failure. That’s why we created IF Method, introducing a systematic approach to software product management for the first time. # IF Method

Bottom left button switches view from Swinlanes to Productbase

IF (iterative-functional) method is an iterative product management tool without any attached methodology — it doesn't uphold any specific principles or values beyond enabling teams delivering customer value in a sustainable way. It's constructed like a Russian doll, mirroring the way developers, designers, and product managers actually build products. Individual contributors work within developer lanes to deliver feature iterations, which together constitute features. The main idea revolves around the triad of engineer queue, feature iteration, and feature. This triad is presented in two views, which can be toggled in the UI. The first view, called **Active Iterations Screen**, displays the engineer queues with feature iterations assigned to each developer. Each feature iteration card remains immovable at all times. The second view, called **Productbase**, represents all the product’s features; it serves the same purpose for product requirements and specifications as a codebase does for code. Once a feature iteration has all its stages marked green i.e. done, it disappears from the **Active Iterations Screen** and can only be found in **Productbase**. But what are stages? ### Stages: The Upside-Down World Everyone is familiar with working on a Kanban board: you create a ticket, drag it from one column to another, and occasionally reassign it to different people. Rinse, repeat, drag it back and forth. If you use Agile and your team has more than five members, every stand-up meeting might involve your product owner scrolling up and down the Kanban board, trying to find certain tickets in various columns assigned to different people. With IF Method, this problem doesn't exist. Status changes are made not by dragging and reassigning but with a single click on the stage indicator. One click turns it from blank to flashing green, indicating progress. Another click marks it as done with a solid green. One more click sets it to blocked, and clicking again resets it to empty. Currently, stages are workspace-wide and set when you configure your Swinlanes for the first time, allowing up to five stages. Five stages are equivalent to 15 Kanban board columns, providing a level of granularity that's hard to achieve with Kanban. Imagine your Kanban board having 15 columns, that would be a mess, wouldn't it? In Swinlanes, every stage has empty, in-progress, done, and blocked statuses. All stage names are editable, though we recommend keeping the last one named "Ready for Users." ### Ready for Users vs. Definition of Done The ticket mentality and inherent ignorance of Agile have ruined software development. Some orgs have a well-defined "Definition of Done" (DoD), which, when fulfilled, sends a ticket off into the void. This allows developers with weaker work ethics to check off requirements and relinquish responsibility for the code they've just shipped. Swinlanes suggests using "Ready for Users" without defining exact steps. If it's ready for users and you're not ashamed of what they see, that's sufficient — there's no need to clarify further. But what happens next to the feature iteration that's ready for users? Unlike tickets marked by DoD that vanish into abyss, they move into the Productbase. # Productbase

Green indicator means a feature has unfinished iterations. Roman number indicates amount of iterations in a feature.

One of the Agile principles — working software over comprehensive documentation — has potentially contributed to internal documentation being a weak point in modern software products (if it exists at all). Yet no one would argue against the need for internal documentation, especially in complex, legacy systems that serve many customers, include custom parts, and are overall large and difficult to maintain. So why do people find maintaining documentation so hard? The main reason is double work. Kanban board tickets and internal documentation exist in two different genres. Tickets are created as user stories, tasks, bugs, and sometimes epics. Internal documentation is usually free-form tale, existing as a single piece. Development often involves changing tickets mid-flight, making it tedious and challenging to find and update all related documentation. The problem is that once documentation is outdated, it can be even dangerous to use, let alone useless. As the old saying goes, “Confluence is where documentation goes to die.” Without proper maintenance, it’s sometimes better to let it go entirely. With **Productbase**, you can view all the features of your product in a single view. Clicking on a feature lets you see all consecutive feature iterations since its foundation, broken down by engineer queues. This approach makes it much easier for new team members — or developers less familiar with a feature — to review iterations, learn about its history, and identify the best person to ask questions. This is a much harder task with Kanban, and hardly anyone does it. It’s also possible to send a feature iteration back to Active Iterations Screen from Productbase by deselecting the green stage indicators on the feature iterations list. This returns the iteration to the developers who were originally assigned to it. # Feature Many project management tools — like Jira — were initially designed as bug trackers, interactive spreadsheets for bugs, whereas product requirements were created in Waterfall-style specs. Kanban boards were a later addition, inspired by manufacturing practices from Toyota car production. IF Method flips this logic. It was not conceived as a bug tracker, it was designed to be feature builder. Every card represents a feature iteration, and any defects — seen as technical damage — are assigned directly to the iteration where they originated. Unlike Kanban tickets, often treated like disposable napkins, feature iterations in IF Method are permanent fixtures. It’s in everyone’s best interest to keep them as engaging and useful as an actual book. The “Shape Up” approach by Jason Fried and DHH emphasises the importance of writing skills in software teams. IF Method also needs and hones this skill: the team should care for the Productbase just as meticulously as they \[should] do the codebase. # Feature Iteration

Feature iteration in the Active Iterations Screen. Note that only the lead developer's iteration displays indicators.

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 reported). Currently, there are no restrictions on the developers' lanes — you can choose the genre and the content style. However, we encourage you to avoid using "Given-When-Then" acceptance criteria and instead use plain, documentation-like 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. 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 solutions 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 IF Method, the usual Agile question — "Should that be another ticket?" — simply does not 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. # Iteration Lead Each feature iteration has a lead who is personally responsible for its delivery. Only this person is entitled to complete the development stage of an iteration and is also responsible for other developers working on it. In the IF Method UI, this is visually represented by the fact that only the lead’s card shows stage indicators. The idea behind this is that team members and stakeholders do not need context about how a task moves back and forth; they only need to know when the deliverable code will be ready for users. Everything else is not important for them and is handled internally by developers. The iteration lead is also responsible for breaking down product requirements into developer lanes. We recommend using the ‘*Reversed Jenga*’ principle: after establishing the architectural contract, developers choose the most distant parts of the feature to work on independently for as long as possible to avoid merge conflicts. The initial part, usually outlining the general file structure and interfaces, is typically done by the iteration lead shortly before other developers start. The lead takes full responsibility for delivery and also has the final say in any disputes over technical questions or implementation architecture. # Technical damage **The term "technical debt"** is as old as software development itself. According to Wikipedia, it refers to the implied cost of future rework when a solution prioritizes convenience or speed over long-term design. Over time, this debt accrues "interest" that needs to be "repaid." We believe that negative impact of this analogy on modern software development is huge. Financial debt is something most people deal with daily — mortgages, credit cards, car loans — and the idea of accruing interest is completely normal, especially when rates are low. Access to debt is perceived positively as a way to achieve desired outcomes earlier. **Technical debt is nothing like this.** Software engineers often quit en masse over unfixable technical debt. It's not unheard of for people to resign on their first day after seeing the horrid state of a codebase. According to the latest[ Stack Overflow Developer Survey](https://survey.stackoverflow.co/2024/professional-developers/#2-most-common-frustrations), technical debt is the top frustration at work for professional developers, cited by 63% of respondents. Technical debt kills the joy of development and collaboration; it frequently destroys entire codebases, which is why rewrites are still so common in the industry. Technical debt does not reflect the true nature of the underlying phenomenon and does not create the vigilance needed to combat it. It’s very hard to persuade business decision-makers to invest in addressing technical debt because its real cost remains hidden from them until it’s too late. That's why IF Method coined a new term: **"**technical damage." It encompasses everything that hinders a flawless, uninterrupted ***user and developer*** experience. This includes bugs, unreadable or convoluted code, incorrect configurations, and broken patterns — all of it is technical damage. This redefinition has serious implications for daily software development. With Kanban, bugs always take priority over low-quality code that needs refactoring, and the latter often gets de-prioritised and buried deep in the backlog. It's hard to justify to the business the need to refactor code that "just works," even if it's spaghetti code prone to bugs nobody wants to touch. **Technical damage is a great equalizer** of bugs and bad code, as well as misconfigurations, DevOps, and SecOps issues affecting the product. ### Bugs Are Anti-Work Kanban boards often encourage low-quality development by representing "user stories" — the actual work — and bugs visually in the same way, making them seem equal in workload. But **bugs aren't work; they're anti-work**. They're additional effort caused by coding errors, missed steps, insufficient checks, and bad decisions by specific individuals. Software engineering is a unique profession where you get paid for your mistakes, usually without major repercussions. The root causes of most bugs remain hidden from engineering and product managers when they should serve as learning material for developers to identify why issues happened and how to prevent them in the future. It's also unfair to have other developers fix someone else's coding errors. That being said, in some cases, fixes from people who introduced the bugs might even make the codebase less stable. IF Method doesn't use a separate visual entity to track issues. Instead, **it provides a separate lane for every feature iteration**, forcing developers to identify where a bug was introduced and who was responsible for that iteration. Some might say this could lead to blame game and a toxic environment. Swinlanes treats it as built-in *radical candor*, expecting professionals to take responsibility for their work's quality. ### We're in This Together Technical leaders often stress the importance of hiring the best engineers with strong work ethics. What they really mean is avoiding those with weak work ethics. Causes of low performance may vary — skill issue, laziness, lack of attention to detail — but the impact of a wrong hire can be devastating over time. A single person who writes low-quality, buggy, or unreadable code can make development unbearable for the entire team, especially if that person influenced early architectural decisions. Later, there won't be enough time to fix faulty foundations. This is also why early startups often have to rewrite their entire products after securing funding. They hire cheap dev shops that create low-quality codebases, and then professional developers can't maintain or extend them. Swinlanes, with its mandatory bug-feature linkage, visually exposes those who don't produce high-quality work. If engineers struggle and are unwilling to improve and learn, they must be let go as soon as possible. Kanban makes it easier to hide low-quality work. In the end though, codebase degradation reaches a point of no return, people leave, and new managers declare that the product needs a rewrite, incurring huge costs to the business. Kanban enables ideal conditions for this kind of death by a thousand papercuts. ### Knowledge Silos Are Technical Damage Another aspect of technical damage isn't just about bugs or unreadable code — it's about overengineering and creating knowledge silos, which is common in the industry. A key sign is when only one engineer can work on a particular part of the codebase because no one else knows it. Sometimes this happens without malicious intent, but fairly often people hoard knowledge, overengineer solutions so others can't easily make changes, and become irreplaceable — sometimes to protect against layoffs. Swinlanes lists all iterations for a feature with all developer lanes, making it easy to see who worked on most iterations. We encourage assigning different developers to subsequent features so people don't get locked into certain areas, lose context on others, and regularly review each other's work. Code reviews are very important, but actually working on someone else's code provides the deepest context. Engineering and product management should not underestimate the danger of knowledge silos. When a knowledge hoarder eventually leaves, the product risks much slower development and more bugs due to lack of context. In the worst-case scenario, you might have to rewrite that part entirely. **Technical damage is an evolving term**, and we'll be discussing it with the community. Please [follow us on X](https://x.com/swinlanes) to keep up with the latest developments. # Cloud and self-hosted versions The IF Method platform is available in both cloud and self‑hosted editions. • Cloud edition Accessible in 3 different regions: | Region | URL | | --------------- | -------------------- | | London / Europe | eu.ifmethod.com | | U.S. East – NYC | us-east.ifmethod.com | | U.S. West – SF | us-west.ifmethod.com | • Self‑hosted edition Designed for deployment on your own server or cloud account. We recommend this option because it gives you maximum control over your data and the system’s uptime. The cloud edition is better suited for teams that want to avoid the extra cost and maintenance effort of managing their own infrastructure. A license key is required to use either edition. To obtain one, email . Keys are issued for 3–12 months and place no limits on the number of users. Without a key, you can only run the platform in demo mode, which is limited to one product and six functions. If you have chosen the cloud edition, you may skip the next page and proceed directly to “Creating a Workspace.” # Setting up self-hosted instance ## 1. Create a virtual machine and obtain IP address We need a cheapest VM up and running, we recommend DigitalOcean.
Select the region closest to the majority of potential users.
For this example, we will select Frankfurt, Germany.
You could select one of the most cheapest options.
Click 'Create droplet' and observe VM being created. Once it's ready, you will see external IP address, which we need to copy.
Now we go to our domain hosting, Vercel. We need to set A DNS records for frontend and backend applications. ## 2. Setting up DNS zone records We will need 2 type A DNS records, one for frontend application and another for a backend server.
Now we need to wait until DNS is propagated. This website tells us when de.ifmethod.com is propagated to 164.92.184.45. ## 3. Platform installation First, we need to log on to virtual machine. In DigitalOcean, that could be done via Console button from VM screen.
We need to make sure we logged in as super user. By default, DigitalOcean logs you in under root. Run `sudo su` to switch to root user if needed. Now we need to download and execute a build script. Run the following commands in sequence. ``` curl -fsSL https://raw.githubusercontent.com/aerlinn13/ifmethod-helm-charts/refs/heads/main/setup_docker.sh -o setup_docker.sh ``` ``` chmod +x ./setup_docker.sh ``` ``` ./setup_docker.sh ``` For first two steps, the script will check and install Docker and docker compose. After that it will prompt you with following questions: 1. App domain (frontend application URL): in our case it's de.ifmethod.com. 2. Api domain (backend server URL): in our case it's de-api.ifmethod.com. 3. Image tag (version platform): the most recent one as of today is 4.25.3. 4. Your email address for self-signed SSL certificates. After you submit all the answers the script will install required images, set up NGINX server, request SSL certificates and reload NGINX server in SLL mode. After build script finishes the platform will be available at the URL you submitted as app domain. # Setting up a workspace ## Step 1. Company name
After logging in using your email and password, you will see a screen where you can enter your company name. ## Step 2. License key
On this step you need to type in your license key. You can purchase one from us by emailing . ### Step 2. Setting up stages
The next screen is about setting up the stages that every feature iteration must go through before it’s ready for users. In IF Method, there are no pre-development stages or “Definition of Ready.” Development always comes first, and its name and position cannot be changed. The rest of the stages can be renamed and rearranged. By default, the form includes QA and [Ready for Users](https://handbook.swinlanes.com/getting-started/pages/I6JWzGnygGlIewYaAATA#ready-for-users-vs.-definition-of-done) instead of “Definition of Done,” and you can add up to two more stages. These could be Code Review, Design Review, or anything else that suits your product. Stages are set during onboarding. They are workspace-wide and can be changed in Workspace settings at any time. # Managing users
This is what you will see once you have stages set up. IF Method does not have a concept of a 'board'. Instead, it has products. On the screenshot, you can see 'The Product' in top left corner. This is the name of your first product, which you could later change. The sign says engineering queues are empty. IF Method has two categories of users, developers and everyone else. Only developers could be assigned to development of feature iterations. Press CMD + J to see the command list opened.

Select "Team"

When you first create a workspace, your account will not have a name displayed. To set it for the first time, use the ‘Actions’ dropdown menu next to your user in the table.
After that you can add additional users to the team. Note that the platform is not yet integrated with an email server, so when you create a user their password is shown only once. You must pass this password to the user through a secure channel. For the same reason, users cannot reset their own passwords. As an administrator you can generate a new password for them and deliver it the same way. If you are the sole administrator and forget your own password, please contact . # Managing products Once all required users and developers are added to the workspace, you can take a look at the ‘Products’ tab. As you already know, IF Method does not have the concept of a board like the Kanban board. Instead, it uses products. Usually, one team works on a single product, which encapsulates one or several codebases.
The Products tab contains two main elements. The first is the product selector. Unlike Jira, which has a board selector on the main screen, IF Method hides this selector in the settings because most people almost never use it — they typically work on their product and don’t need anything else. The second element is the table of products. Here, you can rename your product and add or remove users and developers to or from products. Currently, we advise you not to remove developers from a product, as this feature is a work in progress. Add them as much as you can though. Any user or developer can be added to any number of products. You can also create an unlimited number of products. # Managing features By pressing Command + J, you can navigate to the command menu and select ‘Add Feature.’ You’ll then see the following screen.
Creating a feature essentially involves adding its name and defining the foundation iteration. We recommend using ‘Foundation’ as the name for the initial iteration of every feature, but this is fully customisable.
Please note that every feature iteration, including the foundation one, must have an [iteration lead](/main-concepts/iteration-lead). On this screen, the lead is indicated by a gold star next to the developer’s name. The iteration lead can be changed as needed.
This is what platform looks like when a feature is created. You can see that the iteration appears in both developers’ queues, but only the iteration lead’s queue has stage indicators and the [technical damage](/main-concepts/technical-damage) red heart icon. This highlights that the iteration lead is solely responsible for feature delivery and reporting to external stakeholders, while the other developers report directly to the iteration lead. It’s also useful that all developer iteration cards are highlighted with a blue border when you hover over them, making it easier to see exactly who is working on this iteration. ### Productbase

Productbase view

The Productbase and Active Iterations Screen can be easily toggled on and off using the icon button in the bottom left corner of the screen. The Productbase view displays all the features that have ever been created for this product. When you click on a feature, it takes you to the same feature screen that you can access from the Active Iterations Screen.

Feature screen also allows you to create next iteration

This feature screen, accessible from both the Active Iterations Screen and Productbase views, allows you to add subsequent iterations to the feature. Now, we will add a new iteration called ‘Apple Pay’ to the P2P Payments feature.

Second iteration of P2P feature

The second iteration will be assigned to Dan Daniels and Milana Kurnikova, with Milana as the iteration lead. We also need to assign people responsible for the remaining stages, which in this workspace include QA and the final ‘Ready for users’ stage.
Since we created the feature from the Productbase, we remained in the Productbase view. As you can see, the P2P Payments card now has a ‘II’ Roman number and a green indicator showing that the iteration is in progress. Let's switch back to Active Iterations Screen using icon button on left bottom corner of the screen.

Now we have four developers swinlanes active

As you can see, now we have four developers lanes active, with Milana being iteration lead for second iteration of P2P Payments.

Stage sign-off person is visible on hover

To recap, feature iteration of the iteration lead has stage indicators which reflect state of delivery lifecycle stage. This workspace has three stages, 'Development', 'QA' and "Ready for users'. You can toggle the status of each stage freely, with options for empty, in progress (flashing green), blocked (yellow), and done (solid green). This method offers much more granularity than a typical Kanban board. For example, let’s take a look at this screenshot.

What happened here?

This indicates that development was signed off, while QA and ‘Ready for users’ were blocked, canceled, or not completed. Since no technical damage was added (read heart), there is likely an external reason for this outcome. Another example below.

QA is in progress

This means that development has been signed off (solid green), QA is in progress (flashing green), and ‘Ready for users’ has not yet been confirmed. If you have any questions, please email us at , and we’ll be happy to assist you. Now, let’s move on to the final section, where we’ll explain how to manage technical damage using IF Method. # Managing technical damage Technical damage is a [new term](/main-concepts/technical-damage) created and currently used exclusively by IF Method. It encompasses anything that harms a flawless ***user and developer*** experience. This includes bugs, unreadable or messy code, overengineering, broken patterns, implementation inconsistencies, and knowledge silos. Essentially, it refers to anything that hinders the team’s ability to deliver excellent software quickly and sustainably, without generating further technical damage. The process of logging technical damage with IF Method is different from what you may be used to with a Kanban board. Typically, you’d create a bug ticket and place it in the current sprint or backlog for someone to pick up later. However, IF Method requires that all technical damage be logged against the specific feature iteration where it originated. This means an initial investigation by a developer is needed to identify when and where the bug has been introduced. This linkage significantly reinforces code ownership, allowing everyone to see at all times how much technical damage a feature iteration has accumulated. Now, let’s add some technical damage. Let’s imagine that Milana Kurnikova signed off on the development for the ‘Apple Pay’ feature iteration we submitted on the previous page, and Danil has started the QA process. He found several bugs and wants to add them to the iteration for Milana to fix.

Development signed off, QA failed

In the screenshot above, you can see the first stage, Development, signed off (solid green), while QA has failed (solid yellow). Now, Danil as a person responsible for QA, clicks the red heart button to flip the iteration to the ‘dark side,’ indicating technical damage.

Dark side of the feature iteration

To flip it back, we would click the heart again, but since we want to add technical damage, we click ‘Log Technical Damage’ instead, which brings up the submission screen.
At the moment, we can only use text. Once we submit the technical damage, we’ll see it added.”
We can add new technical damage, mark it as completed, and if there are multiple active technical issues, we can use arrows to navigate through them one by one.
There’s another way to view all technical damages at once. If we flip the card back to the light side and click on it to open the feature view, we’ll see a new black lane called ‘Technical Damage.’ Clicking on this lane will display the full list of technical damages. Currently, IF Method only supports adding and completing technical damages; there’s no option to delete them or add them from the feature view.
The feature iteration in the Active Iterations Screen will also change. Instead of the red heart, a wrench icon will appear, displaying the number of active technical damages.

We have 2 active technical damages here

But what if a bug is found in a different feature iteration that has already been completed? Once the developer triaging the technical damage confirms its origin, they change all stages, including development, to yellow, indicating that these stages need to be redone. For example, if Danil finds a defect that originated in the first iteration of P2P Payments, which has already been shipped to production, he changes all the stages to yellow. The iteration then reappears in the Active Iterations Screen, showing up in the lanes of the developers who were involved in its development so they can fix it. For the sake of workload distribution, it’s not strictly mandatory — but highly encouraged — for developers to fix the technical damage they caused. You can also assign another developer and make them the iteration lead instead to deal with the damage. Another scenario is when you’ve just started using IF Method and a feature has not been created yet, but someone needs to log technical damage against that feature. In this case, you can simply create an empty feature and raise the technical damage against its Foundation iteration.