We found a scenario where your Scrum Board could end up with duplicate tags. Let’s say you had a Shared Backlog which had some tags, and you also had a Scrum Board Template that had some similar tags.
If you created a new Scrum Board using that Backlog and that Template, you could have ended up with some duplicate tags, which is not at all helpful.
We have fixed this.
We used to have Export as HTML and Export as CSV as options for our Task Boards and Scrum Boards, and with our latest version we are tweaking the Export as CSV to become Export as Excel instead.
There are a couple of reasons we did this:
Export as Excel
We are delighted to introduce Planning Views, a very innovative, very unique way to view your Kerika Task Boards and Scrum Boards! (Yes, it goes way beyond what simple calendar views, like those you might get from other tools, work :-))
Let’s start with your familiar view of a Kerika Task Board or Scrum Board, which we will start calling the Workflow View from now on:
There’s now a simple drop-down that appears on the breadcrumbs, letting you switch to one of the Planning Views:
Your new viewing choices include:
Planning Views provide a date-oriented view of your Task Boards and Scrum Boards: a Planning View takes your cards and rearranges into time-oriented columns.
Here’s an example of a Next 3 days view:
Our Workflow view got neatly (and quickly!) pivoted to arrange all the cards in terms of when they are due:
Here’s the same board, but viewed in terms of the Next 3 weeks:
Switching between these views is super-fast, and these views update in real-time: if a due date for any card is changed by anyone on your project team, no matter where they are located, this change is instantly reflected in your view.
The Next 3-months view is an even higher-level view of the board:
All these views support smart drag-and-drop of cards: if you drag a card across, or up/down a column, the Due Date is automatically changed to reflect the new date. As you move the card, the new date is shown in orange so you know exactly what will happen next:
Since your Planning Views aggregate cards that may be in different columns on your Workflow View, we made it really easy for you to see at a glance where each card is in terms of your workflow:
Navigating forward and backward in time is also easy, as is jumping to “today’s view” if you have navigated too far into the future:
As you navigate forwards or backwards, the “And Beyond” column magically adjusts to show you just what’s out of your current view!
Planning Views work just as well with Task Boards (if you are using Kanban) and Scrum Boards (if you are using Agile).
Check out Planning Views — it’s exactly the kind of great design and innovation that you have come to expect from Kerika…
We are often asked how the Kerika team itself uses Kerika, and we freely share this through demos we have done in person for potential customers and at various events. For those who we haven’t met in person, here’s a blog post instead..
1. Kerika runs on Kerika.
Pretty much everything we do, from the smallest, tangential effort to our main product development is done using the Kerika software.
(It shouldn’t surprise you to hear that, given that we are a distributed team ourselves — spread out between Seattle and India.)
2. No email, limited phone calls
In fact, we gave up using internal email back in Dec 2013. (Email sucks, and Kerika is the smarter alternative to spam.)
Because our team is spread out over 10,000 miles, we do occasional phone calls, using Skype or Google Hangouts, to discuss product strategy, but we don’t have daily phone calls as a matter of routine.
We have a phone call only when there is something substantial to discuss, never to catch up on routine status. In other words, all our phone conferences are about interesting topics, like “What do you think about this idea…?” or “I met a customer today who brought up this problem…”; never about “Where are you with Task X?”.
Kerika keeps us in perfect sync across these 10,000 miles on all matters of routine status and project management, so our phone calls are all strategic in nature.
3. Scrum for Product Development
We work with a 2-week Sprint Cycle for the most part, although we have occasionally deviated from this — never with great results, so sticking to the cycle is usually a good idea!
We capture all of our product ideas and feature requests in one large Scrum Board, which we call, simply, Product Planning.
This board organizes our ideas into various buckets, like Valuable for Enterprises and Valuable for Individuals:
You might notice that the Backlog column is relatively small: only 54 items. That’s because not everything in the other buckets is ready to go into the Backlog, either because a feature isn’t well defined enough, or it isn’t considered important enough to deal with in the short-term.
(We have a lot of ideas that sit and gestate for months, even years!)
It’s also worth noting that the Trash contains 62 items: this means we reject as many ideas as we pursue!
4. A Shared Backlog
As ideas for various features get prioritized — and, more importantly, defined clearly enough to be analyzed in detail by our developers — they get moved to the Backlog.
This backlog is shared by all the individual product development Scrum Boards:
(And, by the way, the screenshot above is from a Kerika Whiteboard that we use to map out our product planning process.)
Each Sprint is organized as a separate Scrum Board, pulling items from the common Backlog.
As items get done (or not, as the case may be), the Backlog slowly shrinks over time.
But, as ideas for new features gets firmed up on the Product Planning board, this keeps feeding more stuff into the Backlog. So, the net result is that our Backlog has remained the same size for years: about 50-60 items.
We have been doing this for a while now, and are currently wrapping up Sprint 55, with each Sprint taking at least 2 weeks, and several taking 1 month to complete.
Here’s an example of one of our Scrum Boards:
5. Kerika’s Smart Notifications
So, if we are a distributed team that doesn’t use email, and not that much phone either, how do we keep up with what’s happening? The answer is: Kerika’s smart notifications help each of us easily keep track of changes taking place across literally hundreds of cards each day.
Here’s an example:
At a glance we can tell that this card has
These smart notifications replace dumb email with a much more efficient mechanism for keeping everyone on the same page.
6. The Development Process
If we open up one of these cards, we can get a glimpse of the Kerika development process. Let’s start with the chat thread on this card:
This chat shows a typical interaction between a junior developer and a technical lead: after writing the code for a particular feature, the developer has passed it on to the tech lead for code review.
The code review itself is attached to the card, as an attachment:
For each feature we develop, our engineers create a small work plan that outlines their design thinking.
This design/work plan is a critical artifact for good software development: it ensures that people can review the work more easily and effectively, and it also provides a reference for the future — if ever a bug is found in this particular feature, we can go back to the work plan to see where the design flaw may have originated.
The code review is typically very short, and attached (in this case) as a Google Doc:
7. Card History
Each card in Kerika keeps track of its own history, which makes it easy for a distributed team to keep track of everything that happened. Frequently, a number of changes may have taken place on a single card during a workday, and someone who is 10,000 miles away is also about 13 hours away in terms of timezones, so the history feature is useful for understanding all the changes that took place when you weren’t looking.
So, that’s a typical card, on a typical board. And, in a typical 2-week Sprint Cycle, our development team handles 175-200 cards!
We love Kerika, not just because we have built it, but because it makes our distributed team so very effective!
When you chat on a card, on any Task Board or Scrum Board (or on the canvas on a Whiteboard), the chat message gets sent to the right people as emails.
And who are the “right people”? Well, anyone who is assigned to that card will get the chat sent as email, and Project Leaders can optionally get chat pushed to them as email as well. Everyone else can catch up with the chat when they visit their board.
When chat messages get pushed to you as email, you can reply to them just like regular email (all you need to do is a simply “Reply”, not a “Reply All”).
But, don’t go crazy with emoticons! Most smileys work OK, but not every emoticon will get encoded correctly (using UTF-8).
So, it’s natural to be happy when you are using Kerika, and it’s OK to smile while you work, but don’t use too many strange emoticons in your email replies!
:-)
Right now, the Kerika user interface is entirely in English, but we have users worldwide and many of them use Kerika with other languages, e.g. Greek, Japanese, Korean, etc.
When you export data from a Task Board or Scrum Board that includes non-English characters, the foreign characters are actually preserved correctly as part of the exported data, but if you need to then import data into some other program, like Microsoft Word or Excel, you need to make sure the other program correctly correctly interprets the text as being in UTF-8 format.
WHY UTF-8?
UTF-8 is a coding standard that can handle all possible characters, so it works with languages like Greek, Japanese, etc. which don’t use the Roman alphabet.
For a long time now, UTF-8 has been the only global standard that works across all languages, because of its inherent flexibility in handling different character sets.
When you do an export of data from a Kerika Task Board or Scrum Board, we create the CSV files in UTF-8 format, and include what’s called the Byte Order Mark (BOM) in the first octect of the exported file.
Including a BOM is the best way to let all kinds of third-party programs know that the file is encoding in UTF-8: it’s a standard way of saying to other programs, “Hey, guys! This text may contain non-English characters.”
And for the most part, including a BOM works just fine with CSV exports from Kerika: Google Spreadsheets interprets that correctly, Microsoft Excel on Windows interprets that correctly, but not…
EXCEL ON MACS
Many version of Excel for Macs, going back to Office 2007 at least, have a bug that doesn’t correctly process the BOM character. Why this bug persisted for so long is a mystery, but there we are…
The effect of this bug is that an exported file from Kerika, containing non-English characters, will not display correctly inside Excel on Mac, although it will display correctly with other Mac programs, like the simple Text Edit.
There’s not much we can do about this bug, unfortunately.
THE TECHNICAL BACKGROUND TO ALL THIS:
BOMs are used signify what’s called the “endianess” of the file.
Endianess is a really ancient concept: in fact, most software developers who learned programming in the last couple of decades have no idea what this is about. You can learn about endianess from Wikipedia; the short summary is that when 8-bit bytes are combined to make words, e.g. for 32-bit or 64-bit microprocessors, different manufacturers had adopted one of two conventions for organizing these bytes.
For Big-Endian systems the most significant byte was in the smallest address space, for Little-Endian systems the most significant byte was in the largest address space.
(If you have a number like 12345, for example, the “1” is the most significant digit and the “5” is the least significant. In a Big-Endian system this would be stored as “1 2 3 4 5”; in a Little-Endian system it would be stored as “5 4 3 2 1”. So, when you get presented with any number, you really need to know which of the two systems you are using, because the interpretation of the same digits would be wildly different.)
(About a dozen years ago Joel Spolsky, former PM for Excel, wrote a great article on the origins and use of BOM, for those who want to learn more about the technical details.)
Why this affects Kerika at all? Because when you do an export of cards from Kerika, the export job is run on a virtual machine running on Amazon Web Services.
We have no idea what kind of physical hardware is being used by AWS, and we are not supposed to care either: we shouldn’t have to worry about whether we are generating the CSV file using a little- or big-endian machine, and whether the user is going to open that file with a little- or big-endian machine.
That’s the whole point of using UTF-8 and a BOM: to make it possible for files to be more universally shared.
With our latest release we are adding a feature that will make it easier for folks to create, and maintain, very elaborate Whiteboards: any team member can lock a canvas to discourage other team members from making changes.
This isn’t a very complicated function; it has a very simple purpose: if you have been working hard on a particular canvas, which could be a stand-alone Whiteboard, part of a series of nested canvases in a Whiteboard, or attached to a card on a Task Board or Scrum Board, you may become worried that other team members might come by to visit your board and carelessly make changes to your pristine creation.
(After all, we creative types can get really possessive about our beautiful canvases :-)!)
To discourage others from making changes, just click on the lock button that appears to the far end of the Canvas toolbar:
For Team Members, this is a “soft lock”: any canvas that’s locked by one Team Member can be unlocked by any other Team Member, so you are not really shutting out people from making changes, merely discouraging them by signalling that you would like to preserve a canvas in a particular way.
But for Project Leaders, this is a “hard lock”: if a Project Leader locks a canvas, it can be unlocked only by another Project Leader. (Remember: projects can have more than one Project Leader!)
So, if a canvas gets to a truly pristine state that you want to preserver forever, have the Project Leader lock it, and the rest of the team will be able to view it but not make changes.
And, of course, if canvases are embedded (nested) inside each other, each canvas can be locked or unlocked, as you like, giving you maximum flexibility.
When you have expanded your view of a Kerika board to fill up the browser, using the “Max View” button on the top-right corner of the Kerika app
Another button appears on the top-right, to help you quickly switch between all your open project tabs, as well as get to your Home Page:
This button is color coded to help you understand, at a glance, what’s going on in all your open projects:
Clicking on the button shows a list of all your open projects, along with your Home Page:
The little green arrow (shown above at the top) points to the currently open tab, the one that you are viewing right now.
Projects have a blue icon; templates have a purple icon: in the example above, Statewide Tennis Shoe Distribution is a template, while all the others are projects.
You can reorganize your list of open tabs by simply dragging them up or down this list.
(But, the Home Page is always on the top; that can’t be moved.)
You can also close an open project tab that you are no longer interested in by clicking on the “X” to the right edge of the entry.
So, there’s a simple visual consistency in Kerika’s design:
We finally got around to adding a feature to the Canvas that we have wanted for a while, but somehow never got around to building: now, with a single click, you can change a shape on a canvas, whether it is in a Whiteboard project or attached to a card on a Task Board or Scrum Board:
Here’s why you might need this: often when you are first creating a process flow diagram, you might use shapes — rectangles, ellipses, diamonds — in an arbitrary or careless way, which is just fine because at that time you are trying to be creative rather than meticulous.
But, as the canvas takes shape and matures, you might want to go back and standard the use of particular shapes (even if you don’t strictly follow the old conventions for drawing flowcharts, which we don’t either).
This new function makes it easy for you to select a bunch of shapes and change them all to a new shape. Previously, you had to create a new shape and put it in place to replace the old shape, which was pretty inconvenient when you had a bunch of nested canvases and a bunch of curved lines connecting all the shapes.
Easy, now.
Maybe this isn’t obvious after all… We just realized that a long-time Kerika user (over 3 years of using Kerika on a daily basis!) didn’t know that there is a right-click menu available in Kerika!
If you move your mouse over a card on Task Board or Scrum Board and press the right mouse button, this is what you will see:
This menu is handy for selecting all the cards in a column, which you can then grab and drag over to another column or even mark as Done.