Managing features
Once you have got at least one paid developer license, you’re ready to create your first feature.
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. 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 the Swinlanes look like when a feature is created. You can see that the iteration appears in both developers’ swinlanes, but only the iteration lead’s swimlane has stage indicators and the 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
The Productbase and Swinlanes views 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 Swimlanes view.
This feature screen, accessible from both the Swinlanes 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.
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 Swinlanes using icon button on left bottom corner of the screen.
As you can see, now we have four developers lanes active, with Milana being iteration lead for second iteration of P2P Payments.
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.
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.
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 support@swinlanes.com, 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 Swimlanes.
Last updated
