We fixed a bug that was kind of annoying: if you had a Custom Highlight defined for one board, and then switched to another open board, the Custom Highlight was getting applied automatically to the second board as well.
This happened only if people used the Board Switcher button that appears on the top left of the Kerika app:
Board Switcher
The Board Switcher keeps track of all your open boards and is a fast way to switch between them if you are working on several different projects at the same time — you don’t have to go back to the Home page to find your boards again and again.
Every of your open boards can have Highlights set, or not, as you like. This bug fix makes that a smoother process.
We really like the Tasks feature that we introduced recently: this has significantly cut down on the number of cards that we have to track on boards, since many items can be easily captured, assigned and scheduled as tasks rather than independent tasks.
This means we have a better, epic-oriented view of our boards; we don’t get lost in the weeds.
However, the first implementation of the styling could do with some improvement, so that’s what we did:
Improved styling for tasks
This makes it easier to see the names of people assigned to cards, and the due dates, more easily.
By the way, it took a surprising amount of experimentation before we settled on these colors: in Kerika’s design every color is supposed to have a particular meaning, so that colors appear in a consistent context in every instance.
For example, if we use blue to indicate a clickable link — like we do on the card details left tab, to let you switch between Tasks, Attachments, Chat, etc. — we can’t use blue anywhere else where it wouldn’t be clickable.
So, if blue is clickable in one place, it must always be clickable everywhere else.
This is easy enough, but we also have rules about using colors consistently across actions or displays that seem related, again to minimize the learning effort needed by new users.
Our green is used for Highlights in a consistent way:
What’s Assigned to Me
The breadcrumbs includes the suffix “What’s Assigned to Me” in green, the Highlights button is green to indicate that it is in use, and a green button is used to indicate that items matching the highlight are out of view.
If we are rigorous about this, there is an internal consistency about the Kerika user experience that makes it easier to learn. But it takes a lot of discipline.
So if consistency applies a bunch of constraints in our choice of colors, so do legibility and color-blindness: we have to be careful to avoid using color combinations like red and green that are difficult for some people to distinguish. (About 8 percent of males, and 0.6 percent of females, are red-green color blind in some way or another, whether it is one color, a color combination, or another mutation.)
All of this means that it isn’t easy to pick a new color when we design!
We have replaced the old Filters feature for our Task Boards and Scrum Boards with a new Highlights feature that we think is better in every way!
Click on the Flashlight icon on the top right corner of the Kerika app:
Highlights button
And you will see this menu of actions:
Highlight options
The default is No highlights. We have a couple of built-in highlights that we know you will find useful right away:
What’s assigned to me: very useful if you are working on a large board, or with a large team, and you focus on just what you need to get done.
What needs attention: this highlights all the cards on the board that we think need to pay attention too — items that are overdue, on hold, or flagged as needing review.
Here’s how the Highlights work:
What’s Assigned to Me
A shadow effect helps spotlight all the cards that match the highlight, making them literally pop out of the screen!
If you are working on a board with a lot of columns, there’s always a chance that something that is being highlighted is currently out of view — if, for example, it is near the bottom of a long column.
Kerika takes care of that as well: if a card that matches your highlight choice is currently out of view, a green button appears at the top or bottom, as needed, of each column to indicate that there are cards out of view that match your highlight.
When matched cards are below the scroll
The green arrow acts as more than just an indication that you need to scroll: it is also a button that will scroll the column to show you the next card that you need to see.
(Pretty cool, huh?)
We will be adding more smart highlights in the coming weeks, but in the meantime you can also create your own custom highlights:
Custom Highlights
A Custom Highlight can include any combination of people assigned to cards, status, due dates and tags.
For the due dates, we have offered several smart options that are a lot easier to use than standard date pickers:
Smart choices for Due Dates
These ways of specifying due dates — like “Due Next Week” or “Next Month” — make it even easier to set up a custom highlight.
Our introduction of lazy loading, as part of our recent redesign, was originally limited to just three columns: Backlog (for Scrum Boards), Done, and Trash.
We figured that these columns were most likely to be very long, and would therefore benefit the most from implementing lazy loading.
This worked well; so well, in fact, that we have expanded our use of lazy loading to work with all columns, across all Task Boards and Scrum Boards.
The practical effect of this should be to reduce the time needed by the browser to load large boards, for all users, on all kinds of computers.
We have added a new feature to our Task Boards and Scrum Boards: you can now manage a list of tasks for each card on a board, like this:
Example of tasks in a card
Every card can have as many tasks as you like, organized in a simple, smart checklist.
Individual tasks can be assigned (to one person at a time) and scheduled, and Kerika is smart about rolling up these assignments and due dates to reflect them on the card as well:
Managing tasks in a card
As you mark off tasks as Done, they slide to the bottom of the list to make it easy to see what remains to be done.
We are extending the Column Actions menu (featured in a previous post) to provide a quicker, easier way to hide (or show) individual columns on your Kerika Task Boards and Scrum Boards:
Option to hide column
When a column is hidden, it’s name is shown vertically, so you can easily remember which columns you have hidden at this time.
Hidden columns
Revealing columns that are hidden is easy: just click on the “eye” button and the column immediately comes back into view.
Every Team Member can decide whether to show or hide individual columns: their choices won’t affect the way other Team Members choose to view the same board.
This template contains all the step you need to create your own Customer Journey Map, along with links to articles on the subject from the Nielsen Norman Group.
It’s part of our “Creative Stuff” category of process templates, which includes the Google Design Sprints as well.
Welcome to 2017! We have a big bunch of goodies lined up for release in the coming weeks and months, and we are going to start off with some nice improvements to the 6AM Task Summary email that you can (optionally) get from Kerika:
You now have two options: you can get all your overdue and due items sorted by date, or by board. Or both.
We have also improved the “group items by date”: instead of showing what’s due today and tomorrow, this email now includes What’s Due This Week and What’s Due Next Week.
“This Week” is adjusted automatically as the week progresses to keep track of what’s left for the current week, which always ends on Sunday.
Arun Kumar, CEO of Kerika, and Joy Paulus, Senior Policy and Program Manager for the Washington State Office of the CIO, delivered a joint presentation at the Lean Transformation 2016 Conference.
The subject of the talk was “Collaboration Across Organizations: Big Results with Small Teams”. Here are the slides from the talk:
Interested in using Kerika for software development? Here’s a practical example, taken from one of our own boards, that highlights best practices for tracking, investigating and fixing bugs.
First, a look at our Workflow
Every software development team will want to set up its own workflow, of course, reflecting its internal dynamics and available resources. Here’s the Scrum Board workflow we use in our team:
Scrum Workflow
Our Scrum Boards are organized with these columns:
The Backlog contains all the ideas, large and small, that we have on our product road map: in Scrum terminology, it’s our Product Backlog.
The Sprint Backlog is the set of cards that we pulled from the Backlog at the start of this Sprint: right now, only 4 items are left as we are close to the end of our 2-week Sprint Cycle.
Within each Sprint, cards are picked up developers and first moved into the Planning column, where detailed analysis of the work to be done is completed.
Depending upon the complexity of a particular work item, a developer may request a design review before moving the card further into the Development column.
Developers do their own unit testing as part of the Development phase, but then the work item moves further down to the the QA column which frequently includes formal code review. (More on that below…)
After a bug has been fixed, had its code reviewed and passed unit testing, it gets Deployed to the Testenvironment.
We usually wait until the 2-week Sprint is over before asking the entire team to present the entire Sprint’s output to the Product Owner for the Show & Tell; this avoids distracting the team midway through the Sprint.
Once the output of a Sprint has passed the Show & Tell, it can then be Deployed toProduction.
The Done column shows all the work that got done in this Sprint. That’s where all cards are supposed to go, but sometimes a work item is abandoned and moved to the Trash.
(Side note: we sometimes use WIP Limits to make sure that people are not over-committed to work, but this is not a consistent practice within our team.)
Logging the bug
Now, let’s take a look at an example of an actual bug card that was worked on by our team:
Example of a bug tracked as a Kerika card
(This particular bug doesn’t have a lot in the details, because it is related to another task that is currently underway, and Kerika makes it easy to link cards, canvases or boards.)
Some bugs go into the Product Backlog, if they are not considered especially urgent, but others go straight into the Sprint Backlog if they represent serious production problems that might affect user’s access or the reliability of their data.
Adding bugs to the Product Backlog lets us process bugs along with other development, e.g. of new features, in the same way: everything can be prioritized by the Product Owner and handled through a consistent workflow.
Documenting the bug
Our bug reports typically come with two attachments; at least one of these should always be included so that the developer has a clear starting point for her work:
A screenshot showing the user experience (if the bug can be observed directly by the user.)
An excerpt from the error log, if the server reported any errors around the time the bug was observed.
Original bug report documents
Kerika makes it easy to attach any kind of content to any card, canvas or board: for bug fixing, particularly in the analysis phase, this is very useful if the user needs to include URLs, material from Sourceforge or similar sites, links to Github, etc.
Repro, Cause & Fix
Before any bug is fixed, our developers always add a standard document we call Repro, Cause and Fix as an attachment to the card:
Repro, Cause and Fix
This document is added no matter how trivial the bug.
Why? Because, on average our team goes through about 30-40 cards a week, and has been doing so for years now. If we don’t document our analysis now, we will never recall our logic in the future.
Repro, Cause and Fix
Our team adopts a consistent layout of the Repro, Cause & Fix document, which we adhere to even for trivial bugs:
The Repro Steps are the steps needed to trigger the bug: usually they consist of a specific sequence of actions taken by a user that cause the bug to appear, but they can also consist of a sequence of events in the background, like specific server activity or memory/CPU utilization conditions, or overall network traffic, that trigger the bug.
The Expected Behavior helps clarify the developer’s understanding of the how the software should behave in this situation. It’s not uncommon for a developer who is new to the team to misunderstand how a particular feature is expected to behave, which could lead to more bugs being introduced. Clarifying Expected Behavior in this document provides an easy way for the Product Owner and the Team Lead to confirm that the developer is not going to go down the wrong track.
Introduced Since: our developers try to pinpoint the specific point in the software’s life where the bug was introduced. This helps the developers reflect upon how errors are created in the first place: the blind spots lie in their analytical patterns that need to be strengthened.
(In this particular example, the developer has been able to point back to some of her own work on an earlier feature implementation that caused this bug to appear.)
Root Cause is not the same as the Repro Steps. While a specific sequence of actions or events may reliably display the effects of a particular bug, they only provide the starting point for the analysis; the Root Cause itself is discovered only when the developer examines the code in detail and determines exactly what is breaking.
Affected Feature: all of our code goes through code review, which we view as one of the most effective QA processes we could adopt, but it can be very challenging when you are processing 30 cards each week, each affecting a different part of the software.
Identifying the Affected Feature helps with the code review process, since the reviewer can consider the bug fix in the larger context of the feature that’s being modified. Without this, it is doubtful that we could review so many changes each week.
Affected User: in most cases, this is “everyone” we offer the same Kerika to all our users, whether they are on free trials or have paid for professional subscriptions.
Identifying Affected Users is useful, nonetheless, when dealing with bugs that are browser-specific, or service-specific: for example, determining that a particular bug affects only Kerika+Google users, or only Internet Explorer users.
The Fix: OK, this might seem obvious, but this section really refers to identifying the specific modules in the software that will be changed as a result of the bug fix being applied.
Like many others, we use Git for managing our source code — along with Maven for builds — since our server environment is all Java-based.
The Fix
The Fix section usually includes references to Git checkins: this helps with future bug fixes, by making it easy to traceback sources of new bugs — part of the Introduced Since section described above.
We use separate Git branches for each feature that we develop so that we can decide precisely what gets released to production, and what is held back for future work.
This helps with the Show & Tell phase of our workflow, when the developers demonstrate the output of the Sprint to the Product Owner, who has the option to accept or reject specific features (i.e. cards on the Scrum Board).
Code Review
All of our code goes through code review, no matter how trivial the change:
Code review
We really believe that code reviews are one of the most effective QA practices we could adopt: having a second pair of eyes look over code can very considerably reduce the chances of new bugs being introduced.
So…
Kerika is great for distributed software teams: our own team is spread out between Seattle and India (roughly 10,000 miles apart!), and all of our work is done using Kerika for task management, content management and team collaboration.
Of course, an added benefit of “eating our own dogfood” is that we are highly motivated to make sure Kerika is the best tool there is for distributed teams 🙂
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
