Hi, I’m Tanya
and I’m Maria.
We work as Quality Assurance Engineers in the CLion and AppCode teams
and we are going to show you how we work with agile boards in both our products.
These boards help us manage everyday activities related to development of both IDEs.
Both teams follow a Kanban workflow, so we concentrate more on the work in progress, rather than sprint scheduling and estimations.
We use a single sprint for all of the tasks that are in progress.
Our team decides whether to add an issue to the current sprint based on a queue of prioritized tasks.
This queue is represented by a saved search with a custom order.
We discuss priorities during daily standups and weekly meetings
where members of the team agree on the list of tasks that should be fixed first.
The highest priority issues are placed at the top of the queue.
We use a set of custom fields to facilitate our work with the board.
The “Kanban State” field defines all the possible states that an issue can go through in its lifecycle:
“Analyse”, “Develop”, “Review”,
“Ready to Test” - when development is finished but testing hasn’t started yet,
“Test” - when Quality Assurance starts to look into the issue,
“Merge”, and “Done”.
And this is how the “Kanban State” is represented in the issue.
We added "CIDR" to the field name so it’s not confused with fields in other projects.
Another custom field that we use is “Kanban Track”.
The values for this field define the swimlanes on the board: “Priority” and “General”.
Issues that are moved to the board are added to the “General” swimlane by default.
The “Priority” swimlane is for issues that require special attention and should be resolved as soon as possible.
The value for “Kanban Track” can be easily changed either in the issue or just by dragging a card to the proper swimlane on the board.
You may wonder how an issue gets added to the board.
When a developer wants to start progress on the issue from the queue, he or she just changes the value of the “Kanban State” field.
After that, the issue is automatically added as a card in the “General” swimlane.
You can see that the issue is now assigned to a person who changed the value of the “Kanban State” field.
Normally, cards move from left to right, column by column until they reach the “Done” state.
But there are situations when a card can skip certain columns.
For example, when the fix is trivial and review is not required, the card goes from “Develop” right into the “Ready to Test” column.
When it comes to testing, a Quality Assurance Engineer drags the card from “Ready to Test” to the “Test” column.
The issue is automatically reassigned to the engineer who moved the card to this state.
A card can also move backwards.
This happens when a reviewer is not satisfied with the code
or when Quality Assurance finds a problem during testing.
The board has various indicators that help to visualize the team’s workload.
We set work-in-progress limits for columns on the board that correspond to the number of members in the team.
This helps to control the number of activities that happen simultaneously and highlights areas where the team has bottlenecks.
When the work-in-progress limit for a column is exceeded, it is colored red.
Team members can then coordinate in order to “unload” the red column.
For example, the developers can prioritize code reviews or help with testing.
If the “Develop” column is overloaded, we like to wait until the column gets back to its normal state before we add new cards to the board.
If an issue has tags, these are also displayed on the board.
We have special tags for regressions, for features that need to be documented,
and for issues that were reported or commented by users and require attention from the team.
We can easily add and remove tags right on the board.
The board has a slider to switch the size of the cards from small to extra large.
This comes in quite handy.
When we want to hide the tags or other elements like subtasks and attachments, we set the view to small or medium.
When we need to see more information, like part of the issue description, we switch to XL.
In addition, we have a large monitor installed in our workplace that shows the board in the TV mode.
So, the Kanban board is one of the first things our team members see when they come to work.
When an issue is tested and the changes are merged into all necessary branches, the card is moved to "Done".
We normally keep finished cards in the "Done" column for a while, however, if they start getting in the way, we can easily remove them.
That’s our recipe for tracking AppCode and CLion development activities on an agile board.
If you want try it out, bake your own board following the recipe in this blog post.
Yum!
