We have redesigned the Task/Card details dialog to provide a more space-efficient layout, so you can see more of what you need without having to scroll:
What used to be vertical tabs for Details, Chat, etc., is now a compact horizontal tab; this frees up a lot of space to see the details of the tags.
The other big change we made is to make the Priority setting separate from other Tags:
Clicking on the star will bring up your task priority options:
We are transitioning our Scrum Board users to Task Boards: the Scrum Boards are used only by a tiny portion of our user base, who overwhelmingly prefer using Task Boards and Whiteboards.
For many years now we have offered both Task Boards and Scrum Boards, but the relative popularity (and implied usefulness) of these two are lopsidedly in favor of Task Boards.
The main difference between Task Boards and Scrum Boards has been the use of a shared Backlog: a column of cards that can be shared by several Scrum Boards at the same time.
In Scrum Boards, the Backlog appeared fixed in the leftmost column of the board, and like Done and Trash, it couldn’t be be moved, renamed or deleted.
The Backlog was “live” all the time in the sense that any change made by one attached Scrum Board to the Backlog was immediately reflected in every other Scrum Board that was attached to the same Backlog. If Scrum Board A added a card to a shared Backlog, it immediately showed up in the Backlog column when viewed by Scrum Board B and Scrum Board C.
This wasn’t a good way to implement Scrum Boards, as we found out ourselves during our internal use of these boards. It’s principle weakness was it led to a proliferation of Scrum Boards, since each Sprint required a new Backlog. (Our own development team is currently on Sprint 180 so we experienced this proliferation early on.)
We though the general feature in Kerika that lets accounts archive old boards would help, but this just pushed the proliferation problem to another area; it didn’t really fix it.
We are just going to have Task Boards (and Whiteboards) from now on. At some point in the future we may completely rethink, redesign, and rebuild a new kind of scrum boards, but it doesn’t make sense for us to continue offering the current version.
As a consequence, all existing Scrum Boards will be converted into Task Boards. Here’s how that would work:
Consider an existing set of boards that all use the same shared Backlog: Board A, Board B, and Board C.
Right now all three boards see the same Backlog, at the same time: if cards are added or moved away from the shared Backlog by any board, this view is immediately updated for all three boards.
When we transform Scrum Boards to Task Boards, each of Boards A, B, and C will have its own local copy of the Backlog.
From this point on, any changes made by any of these boards to their local copies of the Backlog will not affect the copies that were made for the other boards. Each board, then, becomes independent and can proceed on its own path, without affecting any other board since there is no longer a shared column of cards.
We have already been in touch with active users of Scrum Boards and have not heard any concerns from them about this proposed change, so we are confident that we are making the right decision. If you do have any questions, please contact us at support@kerika.com.
We have a complete set of templates for folks who want to use the Google Design Sprint methodology; you don’t have to be an expert at either Design or Sprints to get productive fast.
Here’s a quick overview:
We have made some improvements to the process that guides new users when they sign up, so they can join the accounts of coworkers they might need to work with.
The new process works like this:
When a user signs in (with a Google ID, Box ID, or their email), Kerika examines the email address associated with that user and compares it against other users who are already registered.
If it finds that other users from the same domain are already active Kerika users, it offers the new user the option of joining a colleague’s account or starting an entirely new account.
In most cases, people are better off joining accounts that have already been established by their coworkers, so they can find the most relevant Kerika boards.
Kerika tries to be smart about this in a couple of ways:
First, it rules out free domains, like Gmail, Yahoo, and Outlook. (There’s a long list of free domains that we check against.) With free domains, there could be thousands of other users who have similar emails but no connection with you.
So if you sign up with a free email, you won’t be offered the possibility of joining an existing account. (Of course, an existing Gmail user could invite you to join their teams; it’s just that Kerika doesn’t suggest these connections.)
Having winnowed out the free domains, Kerika then considers whether the older accounts from the same domain as the new user can actually accommodate new people: do they have free subscriptions available that could be used by the new user?
If the older accounts are still in the Free Trial phase, then the answer will be Yes: trial users can have unlimited Team Members .
If the older accounts are tagged as Academic/Nonprofit, there’s a good chance they can accommodate new users.
If the older accounts are Professional Accounts, the chances are much lower — unless the older account had bought a few extra subscriptions in advance to accommodate this scenario.
Having further narrowed down the list of potential accounts, Kerika considers whether your potential coworkers are, in fact, active users of Kerika. This is important in universities, for example, that have been whitelisted so that everyone joining up from a particular university automatically gets a free Academic Account.
From University of Washington, for example, there are thousands of registered free accounts, set up over the past several years. Not all are still active because the students involved may have graduated already. So even though an account may have free/unused subscriptions, it doesn’t make sense to suggest that to a new user if that account has been dormant for more than a month.
After all this we could still end up with a large set of potential list of collaborators, particularly in large organizations.
So, as the final step, we check the “last active time” of our candidate accounts and then present the 8 most recently active accounts. Our rationale is that a new user may want to join the most recently active account, which perhaps belongs to a fellow user who had suggested the new user sign up for Kerika.
All of this takes place in a fraction of a second, of course, so users don’t experience any wait times. But it helps new users orient themselves within Kerika by trying to connect them to the most likely coworkers.
Along with the recent improvements we made to the Auto-Number Cards feature for Task Boards and Scrum Boards, we have also made it easier for you to search for cards by their number.
It’s simple to use: just type in a number in the Search box on the top of the Kerika app and Kerika will assume you are looking for a card with that number. It will also search for anything else with that number, but will prioritize a card matching that number as the first result it shows.
Standup meetings, which originated in the Scrum world of software teams, have since become popular with business users, and standups have spread beyond Scrum to teams experimenting with Kanban, and even teams sticking with old school Waterfall.
It’s easy to sell the idea of standups to management and your team members: standups are more frequent, more focused checkpoints help us identify impediments as early as possible.
Let’s consider the four key elements of that sales pitch:
Resist the urge to sit; if you sit, the meetings will get longer and more unfocused.
The great thing about standups that last no more than 15 minutes is that they are easy to hold: any open space will do; you don’t need to book a meeting room.
If there’s no open space, stand crowded together in an aisle. It works: people who can’t get comfortable have an incentive to get the meeting over with.
A daily meeting is actually easier to schedule and has more consistent attendance than a meeting with any other rhythm. It’s easier to remember for everyone to remember that every day has a 9AM standup, than to remember that this particular day has a standup.
Consistency also makes it easier for others to schedule time with you: people always know that you are never available at 9AM, and that’s fine because they have their own 9AM standups to attend each day.
But does the standup have to be at 9AM, or the first thing in the morning?
Nope, there’s no particular advantage to making it the very first meeting of the day for everyone. In fact, it’s better to pick a time that’s about 30 minutes after most people normally come into the office: this gives everyone time to get coffee, catch up on email, and shake off their commute frustrations. People who have just rushed in from a delayed bus or train will not be good contributors to the standup.
As teams transition from Waterfall to Kanban or Scrum, a common objection you will hear in the beginning is people are working on stuff that’s is so complex that there’s nothing to report on a day-to-day basis.
If you face this objection, don’t switch from Daily to Weekly: a better approach is to understand why someone’s work items are so big that they cannot be completed in 1–2 days. Most commonly this is an indicator that tasks have not been broken down to small enough units to accommodate either Kanban or Scrum.
That requires a very tight focus on what matters most. You can achieve that by restricting the agenda to the 3 Questions:
What have you accomplished since yesterday? You should be able to answer this question in just a few seconds: after all, in yesterday’s standup you stated that you planned to get Task X done, so perhaps you need to say today is “Yup, I got Task X done.”
What do you plan to do today? Even this can be answered in a few seconds. Your answer will be “Continue on Task X” or “Start on Task Y”.
You shouldn’t have to explain to people what Task X and Task Y are: that should have been done already at the start of the project cycle, e.g. during the Sprint Planning Meeting.
What impediments are you facing today? This is the most important part of your standup report: when you let coworkers know that you are facing a blocking problem.
Don’t worry about whether the problem you face seems large enough or important enough to report to the entire team. When in doubt, tell people.
The whole point of standups, after all, is to provide the team with an early warning system, so the Scrum Master (or Project Manager or Team Leader; it doesn’t matter what the role is called) can quickly help remove impediments.
The impediment can be as basic as “I don’t know how to solve this problem”: OK, in that case the Scrum Master needs think about where, how, and from whom you can get help.
The impediment might be within a coworker’s ability to remove, like “I need help understanding our purchasing process”, or it may be cross-organizational, like “I am still waiting for Purchasing to sign off on our purchase order.”
Your team should be using a task management system that works for Kanban and Scrum-style projects. An effective system would provide a real-time view of what’s going on, across the team. Something like this:
Spend a few minutes catching up on what’s happened, especially any work that may have been done overnight by a local team. Your system should provide smart highlights to help you focus on the important stuff:
If you are working on multiple projects (and have to attend more than one standup each day), your system should help you see what’s happening across all your Kanban and Scrum boards:
A few minutes spent catching up is a really good way to prep for your standup, and if everyone does it you can be sure of getting done in 15 minutes.
We have added the University of Malaya to the list of domains from which people can automatically qualify for a free Academic Account: anyone signing up for Kerika+Google with a um.edu.my email — students, teachers and administrators — can automatically qualify to have up to 10 Team Members working on boards owned by their account.
Enjoy!
For new users, a new tutorial video on how you can customize the workflow on your Task Boards and Scrum Boards:
Kerika makes Scrum easy for everyone, even people who are not techies. This tutorial video shows how you can set up boards for each of your Scrum Sprints.