We recently found and fixed an odd bug related to the optional 6AM Daily Task Summary email that you can get from Kerika: if you had toggled the preference setting for this email — from ON to OFF, and back to ON again — the email was getting sent at 8AM instead of 6AM.
Essentially a coding mistake on our part, and one we didn’t notice (and none of our users noticed, either) for a long time because no one would try changing this preference setting very often.
The bug’s been fixed.
Views are unique to Kerika: no other work management system provides such an easy way to see what matters, across all the boards you are working on.
These Views make it easy for organizations to really scale up their use of Kerika across multiple projects and many ongoing projects at the same time.
We have now added a very useful new View: What’s New and Updated. As you might guess from the name, this View lets you catch up on everything that’s new and changed, across all the boards you are working on — as a Board Admin, Team Member or Visitor.
This View can work very effectively as a Dashboard for managers who need to keep track of many different boards, all working at the same time: instead of constantly revisiting each board one-by-one, this View is a simple, comprehensive way to see everything that’s changing across all your boards.
The updates are shown in Kerika’s unique “heads-up” notification style: the blue New tags highlight cards that have been newly added to your boards (that you haven’t opened yet), and the orange highlights show you precisely what’s changed on your old cards.
The new and changed cards are sorted into columns, with each column containing all the new and changed items within a particular board. The newest changes appear at the top of a column, and if a board has nothing new to report, the corresponding column is not shown (so your View doesn’t get cluttered up.)
(Cards that are moved to the Done or Trash columns on a board are not included in the View, to help avoid getting the View cluttered.)
As with all Views, it’s easy to operate on all the cards within a column, by selecting the Column Actions button that appears on the top of each column:
The Mark All Cards As Read action is useful if you want to ignore everything that’s going on in a particular board, e.g. when you have just returned from a status meeting where you got fully briefed on what’s happening on a particular board.
Another way to temporarily ignore individual boards is to Hide Column: this collapses the column from the View, and let’s you focus more intently on the handful of boards you care most about.
Selecting a card in this View lets you open the card within the View itself, or to open it on the board where the card actually sits:
(Sometimes it’s easy to deal with cards just by themselves; sometimes the View Board action is more helpful, if you want to be sure you understand the full context in which a card changed.)
Using your mouse’s right-click action will also bring up a bunch of useful actions for that card:
In addition to all the other actions you can perform on cards, you also have the option to get the URL (address) of card using the Get Link action. Every cards, every canvas and every board in Kerika has a unique address, and using these URLs anywhere on a board, e.g. in the board’s details or chat, will automatically set up a link between the two cards.
When you mark a card as “read” on this View, it remains on the View until you click on the Refresh button (shown at the top-right corner of the View).
And, as with all Views in Kerika, the What’s New and Updated View includes the “For Me” toggle button on the top-right corner: clicking this will quickly filter the View to show you just those items that are personally assigned to you.
This feature is available to all our users, just like every other feature in Kerika: it doesn’t matter whether you are still in your 30-day free trial, you are working on the free Individual Plan, or are benefiting from Kerika’s free Academic and Nonprofits Accounts. Everyone always get the same Kerika goodies 🙂
We have improved our Views feature to include a simple toggle that lets you filter the entire View to show just those items that are assigned to you.
This new toggle appears on the top-right corner of the View, and we have added a Tip to help you understand the function:
Clicking on the toggle will immediately shrink the View to show just those items that are assigned to you:
All the other items are hidden from the View, and a simple count at the bottom of each column shows you how many items are assigned to others. In the example shown above, 1 item is assigned to someone else, and is due today.
It’s a simple, fast feature that we think shows the best of Kerika’s design approach 🙂
This feature has been added to all of our Views that need this:
For some time now we have offered the ability for you to hide entire columns on a Task Board or Scrum Board; we are now extending that to Views as well:
In the example shown above, several columns are hidden in this What Needs Attention view, and Kerika shows a count of how many items are hidden in each column.
This feature is available through the Column Actions button that’s at the top of each column:
This can help you focus in on specific work items that need more attention than others.
We have a new (five-minute) video that gives a fast overview of Kerika’s many capabilities:
Let us know what you think!
For users of Kerika’s Task Boards and Scrum Boards, we have made it easier to prioritize your work.
Traditionally, in a Kanban or Scrum board the priority is denoted by the position of the card within a column: cards that are higher priority are placed higher within a column, and the card at the top of the column is the highest priority at that stage of the workflow.
For example, in this view of a board the highest priority item for Planning & Design is the card on top of that column:
This method has the advantage of simplicity and clarity: there is no ambiguity about what is the most important work item at any stage of the workflow.
The disadvantage of this method is that as many cards start to move across the board, especially on boards where the workflow is complex (i.e. the board has many columns), it becomes harder to track all the cards that are especially important.
In other words: the simple method doesn’t scale well, and our goal with Kerika is to provide the simplest user interface on top of the most capable work management system, so we realized we needed to do something more.
With our latest version, Kerika makes it easier to explicitly tag each card with a priority of Normal, High or Critical:
Along with assigning tags to a card, you can now set the priority of the card as well: by default all cards are Normal, but they can alternatively be flagged as High Priority or Critical.
We have also extended the Highlights function for Task Boards and Scrum Boards to make it easy to quickly see all the High Priority and Critical cards on a crowded board:
When you are looking at a board, the High Priority and Critical cards are also highlighted with small stars: a solid red star for Critical, and a hollow red star for High Priority:
The Normal Priority cards don’t have any star; we didn’t want to crowd the design which would have made it harder to spot the more important High Priority and Critical cards at a glance.
And, finally, we have enhanced the What Needs Attention View to include columns for the High Priority and Critical cards across all the boards where you are a Board Admin, or where you have been assigned the card as a Team Member:
We have made it easier for teams to manage multiple Due Dates within the same project, especially when a single work item (as represented by a Task Board or Scrum Board card) contains many different sub-tasks, each of which could have a different Due Date.
Where a card has multiple tasks, each with different Due Dates, the range of dates is shown on cards to make it easier to understand the “time footprint” of the work item as a whole.
Here’s an example of a card with two open/remaining tasks, one of which is due today and the other tomorrow:
When viewed on a Task Board or Scrum Board, Kerika will show the range of dates involved for this card:
This provides better context, better usability for users who work with due dates: at a glance you can see the overall “time footprint” of a work item that involves several sub-tasks.
The What’s Assigned to Me and What’s Due Views are now smarter about handling multiple due dates for the same card: if just one task within a card is overdue, even though the card as a whole isn’t yet overdue, this is shown in the Overdue column in these Views.
Your 6AM summary email (which you can turn on optionally) now lists the due dates on individual tasks within cards, as these become overdue or due this week or next week.
With our latest version, a task within a card (on a Task Board or Scrum Board) can now be assigned to multiple people, just like the card itself.
This makes it easier to handle more complex work items that contain a large number of tasks, each of which may require more than one person to handle.
To make this work, we have also updated the What’s Assigned to Me and What’s Due Views to make sure everyone who is assigned to a task, where tasks have multiple people responsible for them, sees this clearly.
It will come as no surprise to our users that the Kerika team uses the software for every aspect of the company’s internal operations, including, of course, our product development.
(There really isn’t anything better on the market for planning and executing product roadmaps — we know, because we have checked and made sure we are better than everybody :-))
We are sometimes asked about our own internal workflow: how we plan releases and manage our Sprints, and in particular how we have gone without using regular old email for over 4 years now!
Well, here’s a glimpse at our internal workflow:
We work in two-week long Sprints; we have found two weeks to be the ideal Sprint length since it provides enough time to produce something — at least some usable part of a new feature — while not being so long that we forget we are supposed to be working as a Scrum team.
Whenever we plan a new Sprint, we are always also looking forward as well: hence the columns titled “Sprint +1” (i.e. the Sprint that will come after the current Sprint), “Sprint +2” (the Sprint that will come after the next Sprint), etc.
This gives a view into the next several weeks of our product roadmap which makes sure we don’t approach any single work item with tunnel vision.
Now you might notice that “Sprint +3” in the list above is way larger than “Sprint +1” or “Sprint +2”: that doesn’t mean that we expect a sudden spurt in productivity (i.e. increase in team velocity) in 4 weeks time. It just means that as we go further out in our planning there is more uncertainty about priorities and so the Sprints that are well into the future are not well defined — and that’s perfectly OK.
Within each Sprint we have a fairly conventional flow: Planning, Development and QA. The QA step actually consists of three separate stages:
This can be a little scary or frustrating at times: if there was a bad release to our staging environment, it can bring every project and board to a screeching halt. But, from our perspective, that’s the whole point: make it everyone’s business to ensure that we produce high-quality code, and make it everyone’s priority to fix any problems that come up.
This model of living on the bleeding edge of our product gives us a really good incentive to write good quality code!
Very occasionally something will get rejected at the Show & Tell stage, in which case the card gets moved back to Planning or Development and flagged as “Needs Rework”. It’s more common for work to get rejected at the Code Review phase, not because it is buggy, but because it might not meet our internal coding standards.
Once a feature or bug fix has passed Show & Tell, it is ready for Deployment to Production.
We have a continuous integration process for handling code changes — pulling them from our internal git code repository — but we don’t do continuous deployment. Instead we prefer to deploy on the last day of each 2-week Sprint. We usually time this for Friday morning, Indian Standard Time, so that our developers in India can take one final look at the system working in production.
We have an unusually strong emphasis within the team on creating documentation at the same time as we write code. Many small companies skip documentation because they think it will slow them down.
In our own (sometimes bitter) experience, skipping documentation is false savings: if there are problems to be fixed later, or even if a feature simply has to be extended in the future, it’s very hard for even the original developer to recall the logic that she used to write the code in a particular way.
What’s important to note, however, is that we don’t have very big documents: most documents are less than a page long, because they refer to very specific work items. But we have thousands of these small documents, since every feature we have ever produced, and every bug we have fixed, has been documented.
And thanks to Kerika’s very cool integration with Google Docs (we use Kerika+Google), managing these thousands of documents is very easy: just open the relevant card for a specific feature or bug fix and you will find all the relevant documents as well:
For new features we always have a short Planning Document that identifies any existing modules that will be affected and provides an outline of the new code that will be written. Here’s an example:
There may be other documents created, depending upon the complexity of the new feature, but even the smallest new feature will have at least one planning-related document that’s written before the code is written.
For bug fixes, we have a Repro, Cause & Fix document that methodically analyzes the cause of a bug:
The most important section of this document is the Introduced Since piece, where we trace the origin of the bug back to its source, to understand what new feature or bug fix we were originally working on that resulted in this new bug appearing.
This methodical root cause analysis, which we do for even the most minor bugs, helps us identify patterns in our code writing that we need to improve. Sometimes it can even point to bugs that we haven’t discovered yet: the root cause analysis may identify an assumption that we have applied in other places, all of which need to be looked at to make sure there aren’t other variations of the same bug that haven’t been identified yet.
After the bug has been fixed, the Repro, Cause & Fix document is updated to reference the git branches where the code fix can be found. This completes the circle of careful analysis, careful execution, and methodical review that we strive to adopt (and improve continuously).
We stopped using regular email towards the end of 2013. There was never any formal decision to renounce email; instead there was a formal decision to “eat our own dogfood” in a very serious way.
And as we started to build our entire company using our own product, we found that using Kerika is so much better than using email that there really wasn’t any need for email any more.
So people simply started drifting away from email. There was no explicit decision or formal movement to do so, people just realized, on their own, that email is an exceptionally poor way of managing work within a distributed team.
Considering the size of our team — and entire company, for that matter — you may be surprised by the degree of formalism we have adopted, and the heavy emphasis on analysis and documentation.
We spend at least as much time on analysis and documentation as we do on “pure coding”, and if we add in the Code Reviews and other elements of formal QA, the actual coding time is a relatively small portion of our total expenditure.
But trying to skimp on analysis and documentation really doesn’t pay off, in our experience: if you are building a company and product for the long-run, as we very assuredly are, you need to build it right, not just fast.
Every card (and every canvas) on a Task Board or Scrum Board in Kerika has a unique URL, but most of the time you might not notice the URL shown in your browser’s address bar is changing as you open one card after another.
(And if you are using Safari on Macs, you definitely won’t notice this since Safari hides most of the URL anyway.)
These URLs can be helpful in many ways: Kerika recognizes them as pointing to other cards or canvases, and makes these links an easy way to connect up different work items.
Here’s an example of a card URL that’s referenced in a chat message:
Any URLs that are included as part of the chat or details of a card, that reference other cards, canvases or boards within Kerika, are automatically recognized and presented as useful links as you can see from the first chat message shown in the above example.
To make it easier to get these card URLs (and to help you notice that they are important in the first place), we have made it possible to grab any card’s URL with a single click:
Clicking on the new Card URL button that appears on the top-right of each card’s detail view makes it possible to see, and copy, the card’s URL with a simple click:
We have made it easier to grab the URL of an entire board as well, from your Home Page:
Try this way of creating links between related work items, across all your Kerika boards.