Tag Archives: Workflow

About project and process workflows.

UI tweak: removing the “Add member” button from card details

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

As part of our work on combining tags and colors, we have been cleaning up parts of the Kerika user interface that had minor inconsistencies.

One such inconsistency — in our view — was that you were able to add people to a project team from within the card details dialog itself:

Adding people to a team
Adding people to a team

This button has been there in Kerika for a very long time, but it doesn’t really make sense to have this capability within the card details dialog: it just isn’t the best place to decide to add someone to a project team.

Instead, in our new layout the Project Settings dialog consolidates all the board management in one place, including adding people to a team, changing someone’s role within a team, and removing someone from a team:

 

UI tweak: showing attachments in chronological order

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

It used to be that when you added content to a card — files from your laptop or Web content from your Intranet or the Internet, or a canvas — the newest content was added at the top of the list.

Of course, you could always rearrange them, by grabbing and dragging them up or down the list, but this it not a feature that many users discovered on their own 🙁

Rearranging attachments on a card
Rearranging attachments on a card

Well, for greater consistency with how the chat and history are shown within a card’s details, we are now going to show attachments in chronological order as well — the latest files and URLs that you added to a card will appear at the bottom of the list, and the view of these will be automatically scrolled to show the latest items:

 

An easy way of keeping track of sub-tasks

Agile & Scrum, Kanban & Lean, , , ,

With our latest update, it’s become easy to keep track of sub-tasks for cards on a Task Board or Scrum Board; here’s an example:

Using strikethroughs to keep track of sub-tasks
Using strikethroughs to keep track of sub-tasks

In the example shown above, the second item in the numbered list has been been taken care of, and so it has been struck-through, making it clear to the rest of the team that it isn’t an issue any more.

We have added the capability of marking text within card details with a strike-through, and this, combined with the easy way in which you can create numbered lists, makes it easy to track sub-tasks!

Making sure all Project Leaders are equally empowered

Usability,

On any Kerika Task Board, Scrum Board or Whiteboard, you can have as many Project Leaders as you like.

(Normally, teams prefer to have just a single Project Leader, but sometimes it is helpful and appropriate to designate more than one person as Project Leader; among other things it provides redundancy, so that the single Project Leader doesn’t become a bottleneck for handling requests.)

Just how active a Project Leader is depends upon the dynamics of the team: in some teams the Project Leader is just an administrative role, filled by someone who is like a Team Member in every other respect in terms of how much work she takes on, while in other teams the role may be more formal.

It turned out there was a bug in how Kerika handled notifications and requests when there were several Project Leaders on a single board: these notifications and requests were getting routed to just one Project Leader instead of all of them, so there was still a potential for having a bottleneck.

With our latest release we have fixed that problem: now, all notifications and requests get routed to all Project Leaders, so any of them could act upon it. This should remove the bottleneck!

Easier to tell who moved a card to your board’s Trash

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

When a Team Member deletes a card, it just gets moved to the board’s Trash; it doesn’t get immediately deleted from Kerika’s database even though it disappears from your view right away.

That’s because the “delete” action in Kerika is really a “move to Trash” action: you are removing something from view, but not necessarily getting rid of it for good.

Any Team Member can delete a card, but only a Project Leader can completely and permanently get rid of it — in other words, “taking out the trash” is one of the privileges reserved for Project Leaders (and Account Owners).

The Trash column is normally not shown on your Task Board or Scrum Board, but you can bring it view easily by clicking on the Filter button:

Making Trash visible
Making Trash visible

 

With our latest version, it’s easy to see who moved the card to the Trash: we show this right on the card itself.

Seeing who deleted a card
Seeing who deleted a card

“In Progress”: a new Kerika feature

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

We are adding “In Progress” as a new status tag for cards, on Task Boards and Scrum Boards, that we think will make it easier for everyone to see which items are actually moving along.

In Progress
In Progress

Couple of reasons why we did this:

  • People get assigned too many cards sometimes, even when they are working with a “Pull” model (as opposed to “Push”), sometimes even using Work-in-Progress (WIP) Limits don’t solve the problem of easily seeing exactly what’s being worked on at any time.
Template example
Template example

In this process template, we have three buckets of activities: Background Check, IT & Facilities Setup, and Onboarding, and we have a separate In Progress column that you could use to indicate which card is currently in progress.

But, with a “In Progress” status indicator on cards, you wouldn’t need that extra column: you could work on cards from any of those three buckets and indicate their status right there. And when the work gets completed, these cards can go straight to Done!

Filtering by Status: a new feature

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

Here’s another way that Kerika makes it easy to manage really large Task Boards and Scrum Boards: you can use the new Filter dialog to show just those cards that are flagged as having a particular status — for example, you could view just the Critical items, or just the Needs Rework items:

Kerika has several  flags you can use to identify the state of the cards on your board:

Card status
Card status
  • Ready to Pull: this means the card is ready to be picked by someone within the team, in accordance with the project’s workflow.
  • In Progress: this signals the card is being actively worked on by someone; it helps call out which cards are active, among several that may be assigned to the same person.
  • Needs Rework: this calls out the need for a “do-over” of some part of the work — e.g. if a design fails review, or work was not done as expected on a particular card.
  • On Hold: this indicates that the person assigned to that card has put it aside temporarily, usually because the person got diverted by some other work (which presumably is now marked as “In Progress”).
  • Is Blocked: not good; it means that the person who has been assigned that work is not able to progress as they would like to, due to forces beyond their control. Time for the Project Leaders to intervene!
  • Critical: hopefully this gets used sparingly…

Use Kerika’s new Filter by Status capability for your project status review meetings: it’s easy to see which cards are going well, and which ones need help.

Colors+Tags: a much better way to organize large boards

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

We have had both tags and color coding of cards on Task Boards and Scrum Boards for a very long time, but, unfortunately, these operated independently of each other.

There’s no good reason for them to have been separate aspects of working with cards other than simple history: we added color coding many months after we added tags.

Originally we expected color coding to be used in a limited way only: to highlight a few cards on a crowded board that needed special attention.

We had a limited set of 7 light pastels that were chosen to be “color-safe”, i.e. appropriate for use by color-blind people.

Over time, however, we found that people were using color coding a lot more than we had anticipated, and that in fact they were using colors as an alternative to regular tags.

And that was true for the Kerika team as well: we have a “bug” tag that we use to track all work related to defects, but some of us also like to use the red color to highlight cards related to bugs.

And while we could readily agree on the symbolic meaning of a few colors, e.g. Red as indicating something critical or broken, we couldn’t agree on the names or meanings of all the colors.

So, this obviously wasn’t a sustainable path for us: if colors and labels were simply alternative ways of managing your view of a large board, and for collating work across multiple boards, then clearly colors and tags needed to come together as a single concept.

And that’s what we have done with our latest release: colors and tags are now the same thing — all colors have names, all tags can have colors.

Here’s what your Kerika boards will look like, with the new way of showing tags:

New tags styling
New tags styling

A couple of points to note:

  • All your old tags are preserved with this change, so you don’t have to go back and fiddle with any of your old boards.
  • We will show more than one tag on a card at a time; this will make it easier to visually scan a large board.

The dialog for managing your board’s tags has also been updated, to reflect the new merger of tags and colors:

Tags dialog
Tags dialog

When you add a new tag, you have to use a different label from the ones you are currently using: as before, duplicate tags are not allowed.

And the same goes for colors: when you add a new tag, you can’t use a color that is already associated with a label, which means tags have unique colors.

One unique benefit we have added, along with this merger of tags and colors, is the ability to merge tags together.

Let’s say you had been using a tag called “bug” (if you are working on a software project). Some of your colleagues have been using a different tag called “defect”.

You decide that these two tags really reflect the same underlying concept — they are both being used to highlight problems with your software project — so it makes sense to merge these two tags together.

There used to be no easy way of doing this in the past, but now there is:

  • You can merge tags by renaming one of them, e.g. renaming “bug” to “defect” will cause the system the ask if you want to merge “bug” and “defect” together to be same tag.

 

  • You can also merge tags by recoloring on of them, e.g. by changing the color of the “bug” tag to be the same color as the “defect” tag will cause the system to ask if you want to merge these two tags.

 

We hope you like these changes 🙂