With the implementation of our shiny, new and fully automated billing system, it’s become a little more important for our customers to make sure that all the users within their organization are working in the right accounts — preferably, a single account.
Working in a single account, rather than a bunch of separate accounts, has advantages:
It makes it much easier to pay for subscriptions: if all the Kerika users within a department are working on boards owned by a single account, then only that account needs to purchase subscriptions. This means less invoicing and payment stuff for you to worry about.
It also ensures that all project assets — boards, documents, canvases, etc. — are owned by a single entity. And ideally this single entity would be a service account rather than an individual. Many of our customers are using service accounts, set up using emails like firstname.lastname@example.org.
We have done a ton of improvements to the new user sign-up process to help guide people to working with their coworkers, using accounts that the coworkers have already set up, instead of creating new accounts.
But, there are still situations where an organization may find that, across all of its Kerika users, there are too many different accounts. If this is the case for you, we can help: we can consolidate multiple accounts into a single account if you ask us.
This consolidation preserves all the existing boards, content, and project teams: it just changes the ownership of everything to be a single user ID.
The rollout of our new billing system seems to have been smooth — so far, fingers crossed! — and with this you now get better controls over who is part of your Account Team:
Please note that you don’t get charged for Visitors: if someone is only a Visitor on your boards — i.e. is not a Team Member or Board Admin on any board you own — you don’t need to pay for this person.
It doesn’t matter how many boards this person “visits”.
Visitors do show up on your Manage My Team list in the Manage Users tab, so you are reminded that they have access to some, possibly all, of your boards, and you can remove a Visitor entirely from your Account in the same way that you might remove a Team Member or Board Admin.
As part of our next release, which will include a new billing system, we will make it easier for you to move boards that you own to another account.
This can help in several scenarios:
If someone is leaving a team, it’s good practice to have their boards transferred to someone who will remain, so that ownership of project assets — the boards and all the content in the boards, including documents — remains with the team.
More importantly, it is good practice to stay away from having individuals own boards, and instead use service accounts to be the single Account Owner in your organization.
A service account is an omnibus account, typically set up with an email address like email@example.com, that isn’t associated with a single individual. A service account will never quit, never get fired, or take a vacation because a service account is not a real person — it is simply an account/ID used to be the permanent, omnipresent, owner of project assets so that team turnover doesn’t disrupt anyone.
If you own a board, you can move it to another account, i.e. effective change its ownership, by selecting the board on your Account’s Home, and clicking on the Board Actions button which appears on the top-right corner of the board card:
This will bring up a small menu of actions that are available to us as the board’s current owner:
(Note: this menu can also be accessed using the right mouse button.)
When you select the Move to another Account action from this menu, we will present you with this new dialog box:
A list of “known collaborators” is presented to you by Kerika to make it easy to select a coworker with a single mouse click, but you can also move the board to someone else, who isn’t part of your current Kerika collaboration network.
If you type in an email address, Kerika will immediately check to see whether this email address is that of a known Kerika user, before letting you proceed further:
We think these improvements will make it easier for our users to manage their organizations boards, and move towards consolidated ownership for easier asset management.
The Box Platform has some limitations that you may bump into:
Certain characters are not allowed in file names, e.g. “/”. We noticed people were running into this problem, most probably because they were hitting the wrong keys inadvertently when renaming files.
Kerika is going to take of this silently from now on: if you try to rename a file using a character like “/” that Box can’t handle, Kerika will silently ignore that character in your renaming action.
File names can’t be more than 260 bytes. For people using English and similar languages, this generally means a file name cannot be more than 260 characters (with each character requiring one byte of storage). But for most Asian languages, e.g. Thai or Japanese, one character may require two bytes of storage, because the size of the alphabet is much larger than the Roman alphabet used by English.
This means that in some languages, file names may have to be much shorter, depending upon how many bytes are needed for storing each character, which in turn depends upon the size of their alphabets.
Some folks from Thailand were running into this problem: Kerika will start detecting this better, and provide more useful error messages
We have long had a deep, excellent integration with Google Apps: you can sign up with your Google ID and have all your Kerika-related files stored in your own Google Drive, where you can access them independently of the Kerika app.
We are now taking that one step forward, with seamless integration with Google Team Drive.
Google Team Drives are shared spaces where teams can easily store, search, and access their files anywhere, from any device.
Unlike files in My Drive, files in Team Drive belong to the team instead of an individual. Even if members leave, the files stay exactly where they are so your team can continue to share information and get work done.
You don’t need to do anything different: the integration is built-in with the latest version of Kerika (and, since we are software-as-a-service, everyone always uses the latest version of our product!) and the integration is seamless.
We have a complete (one-hour long) video of the tutorial presented by Arun Kumar, CEO of Kerika, at the recent Lean Transformation Conference on the subject of Kanban vs Scrum: what’s the difference, and which should you use?
(The slides for this talk, and more, can be found on Slideshare.)
Forming a team 00:01:32
The Product Owner 00:02:01
The Scrum Master 00:02:55
The Scrum Team 00:03:55
Pulling Work 00:04:04
The Product Backlog 00:05:45
Scrum Stories 00:06:25
Writing a good Story 00:07:35
From Epics to Stories 00:10:25
From Stories to Tasks 00:11:13
Estimating with Story Points 00:13:04
Organizing a Sprint 00:15:00
How long is a Sprint? 00:19:15
Sprints in theory 00:20:32
Sprints in real-life 00:20:53
Daily Standups 00:23:25
Burndown Charts 00:24:13
Team Velocity 00:25:35
Best Practices for Getting Scrum Right 00:28:00
The Nuclear Option 00:30:57
Where does Scrum work best? 00:32:02
Scrum in Government 00:33:25
Where does Kanban work best? 00:35:43
Collaboration Networks 00:37:25
Paper doesn’t scale 00:38:30
Using Kerika for Personal Kanban 00:39:50
Using Kerika for Team Kanban 00:40:24
Using Kerika in the Public Sector 00:40:37
Using Kerika for Scrum Projects 00:40:54
Capturing stories as “virtual sticky notes” 00:41:20
Question: how do you deal with poor performers on the team? 00:49:15
Question: in Scrum, are units of measure like lines of code still applicable? 00:50:08
Question: how do you measure individual performance? 00:51:03
Question: how do you handle poor performers within a team? 00:52:25
Question: when do you use the Nuclear Option? 00:54:20