Ben Vaught from the Washington State Office of the CIO has come up an interesting use-case for Kerika’s new export feature that we hadn’t considered: use it to write your weekly status reports!
Kerika lets you export cards from a Task Board or Scrum Board in CSV or HTML format: the CSV format is useful for putting data from Kerika into another software tool, like Excel, but the HTML format is designed for human consumption.
Here’s an example of a card that’s been exported as HTML:
Example of HTML export
By using the Workflow button (on the top-right menu bar), you can adjust your display to show just the Done column on a board, and then further use the Tags button to limit the number of cards that are shown in this column.
For example, you could display just the Done column, and filter the cards to show just the ones that were assigned to you.
Do an HTML export of this, and you will be able to easily cut-and-paste the output into a Word document or email, and submit your status report!
A couple of weeks ago we visited a UX team at the Washington State Department of Licensing, and took a photo of the “Post-It Palace” they had built within their cubicles:
We did a quick refresh to Kerika today, and we will be quiet for a while our development team — which is based in India — takes a well-earned Diwali break for about 2 weeks.
With our newest release, we have added a new status indicator that you can use to flag particularly important cards on a crowded board: “Critical”.
Critical status
The reason we added this was simple: no matter how cool and calm we try to be, every so often there’s a mini-crisis and we need to make sure that everyone takes note of some particular cards.
In the past we tried to accomplish this by use of color (e.g. Red), but this wasn’t a satisfactory solution since we want to use colors for other purposes as well.
We also tried marking critical cards as “Is blocked”, because this indicator appears in red text making it very eye-catching, but this too was not a satisfactory solution.
“Critical” works: you can highlight really important cards on a board by marking them with this status, and you can also search for Critical cards as part of Advanced Search.
Most users work on private projects: i.e. projects that are accessible only to people added to the project team.
But some folks find it useful to have their projects viewable by everyone, typically because they are working on nonprofit causes, like WIKISPEED.
WIKISPEED publicizes its projects because it helps attract new volunteers to their cause, and this is actually a pretty smart way for nonprofits to showcase their work.
Kerika has always had an option for people to have all their projects made viewable by the public, but even nonprofits, for example, may have some Kerika boards that they don’t want to share with the rest of the world.
Well, with our newest release, it is possible for the Project Leader (or Account Owner) to make individual projects open to the public to view.
A project can be easily switched from Private to Public, and back again, using the Project Info button that’s available on the top-right of every Kerika board:
Privacy
The privacy choices are as follows:
Only the project team can access: this is the default setting, and it means that unless people are added to the project team, they won’t be able to view it — or even find it using the Search function.
Anyone, anywhere can view: this means the project is “public” — it can be found through search, and anyone who knows the URL of the project can view it. (But, they still won’t be able to make changes.)
When a project is made Public, all the documents contained within it — on all the cards and canvases that make up that board — are also made viewable to the public.
This means, for example, that if your Kerika+GoogleWhiteboard or Task Board is made available to the public, all the documents in that board’s Google Docs folder are also made viewable by the public.
(And Google indexes all public Google Docs, the project could be found in more than one way, depending upon who is searching for it.)
One caveat: users of premium Google Apps, e.g. Google Apps for Business, cannot make their projects open to the public, because of limitations imposed by Google.
When we first started working on Kerika, it seemed to us that everyone who wanted to use an online project board fell into one of two camps that didn’t overlap:
Kanban users, who wanted a simple Task Board, perhaps with nothing more than To Do, Doing, and Done columns.
Scrum users, who wanted to share Backlogs across multiple Scrum Boards, with each Scrum Board representing a different Scrum iteration (i.e. “Sprint”).
Folks who wanted to work in Kanban-style – typically business users – seemed to have little use for Scrum, and people who wanted to work in Agile-style – typically IT folks – didn’t show much interest in Kanban.
So, we built Kerika with support for Task Boards, for Lean/Kanban users, and Scrum Boards, for Agile users.
What we are seeing more recently, however, is spectrum of usage patterns and styles within organizations:
A project that starts off as a Kanban Board might need to become a Scrum Board in the future: as the team works on the project, it may conclude that a series of Sprints/iterations is a better model than a continuous flow/Kanban model, and they may need to transform their Kanban Board to a series of Scrum Boards.
A team might start off working with Scrum Boards, thinking that Agile is the ideal model for their work, and then find that a Kanban model of continuous flow is better suited for their needs, in which case they may need to change from a Task Board to a Scrum Board.
A Scrum team may need to pull items from multiple Backlogs: there may be items from a Marketing Backlog and from a Product Development Backlog that need to get worked on in the same Sprint, so the team may need to switch from one Backlog to another.
This kind of flexibility wasn’t available in Kerika before — and is certainly not available in Trello, Asana, Basecamp or any other tools that compete with Kerika — and that’s exactly the problem that we have fixed with the new release!
Use the Project Info button, on the top-right of the Kerika menu bar, to switch a board from Kanban to Scrum, or vice versa:
Settings
If you check the “Use a shared Backlog” box, you can then select the Backlog you want to use for your board: if you had been working in a Kanban board, it automatically switches over to a Scrum Board.
At any time you can switch between any of the Backlogs that exist in the Account, that you have permission to access.
If you want to go back to working in Kanban-style, just uncheck the “Use a shared Backlog” box and the Backlog will disappear from view.
It’s now that simple to choose between Kanban and Scrum!
We are thrilled to announce a great new feature: Work-In-Progress (WIP) Limits for Kanban Boards and Scrum Boards.
WIP Limits are a very helpful tool when you are working in a true Kanban style: where work gets “pulled” as people become free, rather than work getting “pushed” onto people before the people ready.
To understand the difference between “push” vs. “pull”, think back to that famous episode of “I Love Lucy” where Lucy and Ethel take up jobs at a chocolate factory, and quickly find themselves unable to keep up with all the work that’s getting pushed onto them:
This is a perfect example of the perils of “push”: as the chocolate gets prepared upstream, the work becomes ready even though the people aren’t ready for the work.
If you push work on to people who aren’t ready to take it on, you will quickly have disastrous results. (It’s funny only when it’s on TV and it involves Lucy.)
At the very least, you will have an imperfect understanding of what each person is actually doing, if people upstream in the project’s workflow simply push work downstream as soon as the upstream folks are done with it.
A pull model is different: people “pull” work and assign it to themselves when they are ready.
Each person typically has a small number of items they are juggling at any time: it may be as few as two items, depending upon the complexity of the work, but it is rarely as few as just one item.
(You nearly always want to have one “background” task ready to be picked up whenever your “foreground” task gets blocked for any reason.)
When a person is able to take on a new task, she can “pull” a card from the column to the left of her on a Kerika board.
Here’s a simple example, reflecting the workflow for a software project:
WIP Workflow Example
This project includes people with different roles: designers, developers and QA, and each group has determined it’s own WIP limits, based upon the team’s capacity and velocity.
In this particular example, we can see that the Planning & Design and Deployment columns have currently exceeded their WIP limits (and, in the case of Deployment, by a large margin!)
When this happens, Kerika alerts you to the condition by showing the affected columns with red text in the column headers:
Example board with WIP exceeded
WIP Limits as “soft limits”: Kerika doesn’t stop you from exceeding a column’s WIP Limit, but it does provide a very clear, visible warning to everyone that a bottleneck is about to form.
When bottlenecks start to form, the Project Leader should intervene and help manage the upstream flow so that the WIP Limit can come back to its acceptable amount.
WIP Limits originated in Kanban, but Kerika lets you use them for Scrum Boards as well!
To use WIP Limits, click on the Project Info button that’s at the top-right of the Task Board or Scrum Board:
OK, so our website has long stressed the word “unlimited”, and maybe that’s not such a great idea…
Most people have boards with a few dozen cards.
Some folks have boards with a couple of hundred cards.
Very few people have boards with up to 1,000 cards.
It turned out that one of our users had a board with nearly 4,200 cards, of which over 4,000 were in the Trash.
And that’s not good! A board with several thousand cards on it is going to take a long time to load, because each card has many different attributes to it: details, chat, assignments, status, history, etc.
And when someone with a very large board uses Kerika, this can cause very unexpected loads on the servers, particularly in terms of network I/O and CPU utilization.
This is what it looks like when someone suddenly opens a board with thousands of cards on it:
Most of the time, boards get very big because they are very old: stuff piles up in the Done column, or, as in this case, in the Trash column.
Having very large boards can impact performance: unlike, say, email which you may be accustomed to leaving piled up in your Inbox for years on end, Kerika’s cards are “live object”: even when a card is in the Done or Trash columns, it is constantly listening for updates from the server, because it could be moved out of Done or Trash at any time by someone on the team, or have some of it’s attributes changed.
For example, even though a card is “Done” or “Trashed”, it could have its details updated, or new chat added to it.
This is different from email messages, which are essentially “dead objects”: once you get an email and read it, it doesn’t update after that, so it can sit for years in your Inbox without trying to get fresh updates from the mail server.
So, when you have 4,200 cards on a single board, you have that many live objects trying to get updates from the server at the same time, and that’s not good for your browser or our server!
(Imagine your laptop trying to read and display 4,200 emails at the same time, and you will get an idea of the problem…)
Having very large boards is not a good idea from a workflow or process management perspective, and so perhaps Kerika needs to do something about it: we need to think about how we can help our users improve their workflow, while also avoiding these CPU spikes.
A couple of ideas that we are considering:
Start warning users when their boards are getting too big.
If boards hit some threshold values (which we have yet to figure out, maybe it’s 1,000 cards?) force the user to reconfigure their board so they don’t affect the quality of the service for everyone.
To access this feature, simply click on the Project Info button that’s shown at the top-right of each Kerika Board, and you will see the Project Info display (that we have talked about in an earlier blog post):
Export
CSV format is useful if you want to want to take data from Kerika and put it into Excel or some other analysis tool;
HTML format is useful if you want to print material from Kerika, or insert it into Word, PowerPoint or similar tools.
With both CSV and HTML exports, hidden cards are not exported: this means that if you are currently choosing to hide some columns (by using the Workflow button), or hide some cards (by using the Tags filters), then the cards that you are not viewing right now will not be part of the export.
When you export a board in CSV format, you get the following data, for each visible card:
Example of CSV export
Column Name: e.g. Backlog, In Progress, Done, etc.
Card Name: e.g. “Create PR news release”.
Card Description: e.g. “We need to create a PR news release once our latest version is ready…” (Rich text will be converted to plain text, since CSV files can only deal with plain text.)
Status: e.g. Needs Review, Needs Rework, etc. (If the card doesn’t have a special status, “Normal” will be shown.)
Due Date: the date the card is due, if a date has been set. (If the card doesn’t have a Due Date, “Not Scheduled” will appear.)
Assigned To: a list of names of the people the card is currently assigned to. (If the card isn’t assigned to anyone, “Not Assigned” will appear.)
Exporting could take a while: the exported data are put into a file in your Google Drive or Box account — depending upon whether you are using Kerika+Google or Kerika+Box — and when the process completes, you get an email with a link to the file containing your data.
It’s a similar experience if you do a HTML export; however the format of the data is different, giving you an indented set of attributes for each card, like this example from a Kerika+Box project:
Example of HTML export from Kerika+Box
One caveat about exporting HTML: if you open the results in Google Docs, Google shows a preview of the output, and that doesn’t look good: instead of rendering the HTML, Google actually exposes it.
Here’s an example from a Kerika+Google project:
Example of HTML export from Kerika+Google
The export feature can be used for many different purposes, of course: the most common scenario we envision is people wanting to include material from Kerika in their analysis and presentations.
And, of course, one use would be for government agencies that have to respond to Freedom of Information Act (FOIA) requests, or other Sunshine laws.
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.
