Tag Archives: Kanban

About Kanban. See also Lean.

A simpler menu for cards and columns on your Task Boards and Scrum Boards

Agile & Scrum, Kanban & Lean, Kerika, Usability, , ,

We used to have separate button, and associated menus, for actions related to cards and for actions related to columns:

Separate card and column actions
Separate card and column actions

This reflected the history of the Kerika product: we first designed and built the card actions, and much later added the column actions.

In retrospect, however, we concluded that separating these into two separate menus was not a good idea: it was confusing for our users to remember which menu supported which action. (Even the Kerika team, which uses Kerika for everything that the company does, was having trouble remembering the differences between the two buttons and menus.)

We have fixed that usability problem with our latest release: a single button is shown, and the popup menu that appears includes both card actions and column actions:

Combined Card and Column Actions Menu
Combined Card and Column Actions Menu

Clicking on the Sort and Move actions brings up all the sorting and moving options you have; the Sort menu now has a much richer set of actions:

Sort options
Sort options

We have also done some small tweaks to the sorting action: Sort by Status now puts the On Hold cards at the bottom of the column, below all the ones flagged as Normal.

Using Service Accounts to manage all your Kerika Users

Agile & Scrum, Team Collaboration, Technology, , , ,

For some segments of our users, e.g. college students using Kerika for their course projects, it makes sense to treat each user as an independent entity, since the relationships between these students will vary from class to class, from semester to semester.

These collaboration networks are very dynamic, and it’s impossible to predict whether a team that got together to work on a three-month class project will stick together after that project is over, or work as the same group of people on the next class project.

In business environments (companies, nonprofits and government agencies), however, the teams are more stable: people don’t change jobs every few months.  But, turnover can still be a problem: if Joe leaves your company, how can you be sure that all the boards and documents that Joe had created are not lost along when Joe is gone?

The simple solution to this is to use service accounts to own all the boards that are being used by a community of users, like a department or even the entire company (if the company is small enough).

A service account looks like any other Kerika account — it is associated with it’s own email, e.g. kerika@example.com — but it isn’t actually a real person: the email will have been set up by the organization’s IT staff or management, and the password is typically shared between a small handful of supervisory people.

Unlike real people, service accounts will always stick around: they won’t retire, resign, or get run over by a bus…

This means the organization has continuity and security with respect to it’s Kerika boards and documents: because the project assets are owned by kerika@example.com, rather than joe@example.com, it doesn’t matter whether Joe is still working at the company or not.

We encourage all our professional users — people working in companies, nonprofits and governments — to set up service accounts as a best practice, and we can help you: just email us at support@kerika.com and we will do all the account consolidation for you:

  • All the boards owned by the people in your organization will be transferred to the ownership of the service account instead.
  • Everything about each board is preserved as part of the transfer: all the cards, canvases, due dates, etc. remain the same after the transfer; it’s just that the boards are no longer owned by joe@example.com and susan@example.com, but instead are now owned by kerika@example.com
  • You can decide who to consolidate within the service account: typically it is everyone in the organization, but if you have different departments or cost centers, it will make sense to have more than one service account — one for each department or cost center.
  • After the consolidation, individual users within your organization will no longer have separate accounts: their Kerika identity, preferences, history, etc. are all preserved, but instead of working in several different accounts, they will all be working in a single service account, that’s under the control of your organization.
  • All this can be done by us, overnight: the next day your users can come into work and login as they did before, and have access to all the boards they had the previous day. All the boards will look the same, and your users can pick exactly where they left off.

When users have been consolidated within a service account, any new boards that they create will automatically be owned by that service account, rather than by the individual users.  This ensures that all current and all future project assets are owned by the service account, i.e. by the company, rather than by individual users.

It’s still possible for individual users to have privacy within the service account: for sensitive work (e.g. personnel matters) they can adjust the privacy of individual boards to be “share with board team only”.  When the privacy is set to board team only, the board will be visible only to the people who are specifically added by the Board Admins to the board’s team.

The Account Owner, i.e. the service account, will always have access to every board within that account, regardless of the board’s privacy settings. This is consistent with how other organizational assets are currently managed: if you have a work email, for example, you expect to have privacy from your coworkers, but you know that the company’s IT department will always have access to your email if they need it — and your email doesn’t really belong to you, but to your employer.

Seeing at a glance what’s hidden

Agile & Scrum, Kanban & Lean, Technology, , , ,

If you hide a column from your view of a Task Board or Scrum Board, Kerika now makes it clear whether this column has any cards or not:

Hidden columns
Hidden columns

In the example shown above, the Release Notes column is empty, so it is shown in a light shade of grey, while the Final Review column has at least one card, and it is shown in black.

Kerika also helps you see, at a glance, whether the columns you are hiding have any updates you haven’t caught up on, or cards that are overdue:

Hidden columns with updates and overdue dates
Hidden columns with updates and overdue dates

The orange icon in the example above shows that the This Sprint column contains cards with updates on them that you haven’t caught up on yet, and the red icon shows that the Planning column contains overdue cards.

We have added support for Google Team Drive

Agile & Scrum, Kanban & Lean, Team Collaboration, Usability, , , , , ,

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.

Team Drives is available on G Suite Enterprise, G Suite Business, or G Suite for Education editions.

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 made it easier to have more complicated tasks inside cards

Agile & Scrum, Usability, , , ,

When we first added the ability for you to add a list of tasks to a card on a Task Board or Scrum Board, our expectation was that these tasks would be short and to the point: maybe just a few words long.

And to make the display of tasks neat and tidy inside a card’s details view, we truncated long tasks to show just two lines worth.  We figured this was a reasonable restriction that would make the layout look better, and wouldn’t actually inconvenience anyone since we really didn’t expect people to create very complex tasks, that might take more than one sentence to spell out.

Well, that turned out to be a bad assumption: the tasks feature turned out to be far more popular than we expected, and we soon started getting complaints from people that didn’t like seeing their tasks get truncated to two lines.

We have fixed that with our latest update to Kerika: now, all tasks will show fully, no matter how long they are. Here’s an example:

Example of long task
Example of long task

In the example shown above, the first task is long enough to spill out over three lines, and all three lines are shown.

So, there you go: tasks became a little more flexible!

Bugs, fixed: edge cases where due dates on tasks weren’t being reflected correctly at the card level

Agile & Scrum, Bug Fixes, , , ,

If you create a list of tasks on a card on a Task Board or Scrum Board, Kerika does a bunch of stuff in the background to make sure your view of what’s due, at the card level, board level and account level, are always correct.

We found a couple of edge cases where the due dates on tasks wasn’t rolling up correctly to the card level, potentially giving users a misleading view of what was currently due for them:

  1. When the last task with a scheduled due date was removed (deleted) from a card, this wasn’t correctly adjusting the due date for the card itself.
  2. Similarly, when the last task with a scheduled due date was no longer scheduled, this wasn’t correctly adjusting the due date for the card.

Both bugs have been fixed. They were real edge-cases, so it’s likely that most users never noticed them in the first place, but still…

 

Kanban vs Scrum: what’s the difference, and which should you use?

Agile & Scrum, Government, Kanban & Lean, Kerika, Tutorials, , , , , , ,

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.)

Topics covered:

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

Summary 00:42:57

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

Question: how do you estimate stories? 00:55:54

Photo credits: Abdul-Rasul Kassamali, Jama Abdirahman.

We made it easier to prioritize work

Agile & Scrum, Kanban & Lean, Usability, , , ,

For users of Kerika’s Task Boards and Scrum Boards, we have made it easier to prioritize your work.

Background:

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:

Highest priority item in Planning and Design
Highest priority item in Planning and Design

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.

Flagging cards

With our latest version, Kerika makes it easier to explicitly tag each card with a priority of Normal, High or Critical:

Setting Priority
Setting Priority

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.

Viewing all the High Priority and Critical Cards

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:

Highlighting high priority and critical items
Highlighting high priority and critical items

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:

High Priority and Critical cards
High Priority and Critical cards

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.

High Priority and Critical Cards across all your Boards

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:

What Needs Attention View
What Needs Attention View

Managing multiple Due Dates became easier

Agile & Scrum, Kanban & Lean, Usability, , , ,

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:

Tasks with different due dates
Tasks with different due dates

When viewed on a Task Board or Scrum Board, Kerika will show the range of dates involved for this card:

Tasks with a range of Due Dates
Tasks with a range of Due Dates

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.