You are currently browsing articles tagged process.

A good way to know if your team is using their taskboard to really manage their work is to look at their daily standup meeting.

Does it look like this:


or like this?


A team that is using visual management to manage their work will always do their daily standup against the board. During the daily standup you update your team members on your work. Both work finished the day before and work still in progress should be clearly indicated on the board. It only makes sense to go over the board as you talk. This is both easier for you and easier for team members. It also helps to visually place what you are talking about in context.


If you are using the DONE tag, nametags, status tags and the three columns; then there is a very simple guideline to make sure you don’t forget to talk about anything important every day: do the daily standup against the board, and make sure all tasks in the middle column (“in progress”) are talked about.

Tags: , , ,

“Unplanned items and legacy issues” is the top row on my scrumboards. Instead of a story, it is a placeholder for:

  • Unplanned work: stuff that we suddenly have to do and we can’t plan (meaning we cannot put into the backlog as a story). A typical example is reinstalling a PC after a hard drive crash. You might spend all day at this, and you are obviously not going to wait until the next sprint to fix your PC.
  • Legacy issues: this is any bug or issue that belongs to stories already delivered and accepted, and should be fixed.

Why do I put this on top? For unplanned items it’s rather obvious: this is for things you are doing anyways, and are not part of any story. Most teams simply don’t visualize this type of work, but I like all work to be visible, even if it doesn’t add value. Otherwise the day is gone and “nothing” was done. This way at least everybody knows what you are doing.

Regarding legacy issues, a general best practice is to fix bugs before writing new code, and implement all feedback from the Sprint Demo before starting with new stories. If you follow those guidelines, legacy issues should have priority over new work.  (If for any reason it doesn’t, then put it either in the backlog or in the parking lot).

In both cases, we are assuming the work is relatively small. That means tasks, not stories. At most a couple of days of work.  For example, during the Sprint demo, the customer might make a small observation that takes one or two hours to fix. A small change request if you want.  How are you going to manage this work? Are you going to create a new story for this? Too much overhead… just put up a task (a post-it) in Legacy Issues, get it done with and forget about it. But be careful with this and always use common sense. If it is story-size work, there is really no excuse not to plan it, it is the PO’s responsibility to tell the customer it will go in the backlog and the best he can ask for is top priority for the next sprint.


Tags: , , ,

Visual management is not just about having visual elements, how you use them is equally important. A bad process can render a good idea useless. And some trivial ideas, with a good process behind them, can produce interesting results.

The DONE status tag is a process related idea. It is a creative way to visualize flow, give teams a moment to celebrate their achievements, and to ensure team alignment and communication; all on a daily basis.

The DONE tag

The concept is simple. During the day, team members work on tasks that are in the “In progress” column of the task board. When they finish a task, instead of immediately moving it to the “Finished” column, they slap a DONE tag on it. And there it stays for the rest of the day, broadcasting to the world that the team has finished some work. This is the flow part: at a glance, at the end of the day you can “see flow” by scanning the boards for DONE tags. The more blue, the more flow. Managers and Product Owners like this.

The celebration part comes during the daily standup. Here, the team gets to move all their DONE tags to the Finished column, creating a small daily moment of pride. Naturally it should be the person who finished the task who talks about it and moves it.

What about alignment and communication? By moving all DONE tasks at the daily standup, you basically ensure that everybody in the team is aware of what is getting finished and by whom. This is actually how the idea came up. Team members were moving tasks to Finished during the day, and then at the daily standup they would forget to talk about stuff. With lots of tasks in the Finished column, it was getting difficult to remember which ones were new from the day before. And if you have One Day Tasks, believe me, this is going to happen, especially with the most prolific developers who get a lot of stuff done. The idea was to come up with a foolproof process that would guarantee people would talk about everything they finished the day before without requiring a special effort on their part. This worked, and people liked it.

So the general guideline for using the DONE tag is:

  • You should only move tasks to the Finished column during the daily standup.
  • You should only move tasks that have the DONE tag on them and you did yourself.
  • Once you move them to the Finished column, remove the DONE tag.

Another curious thing I discovered is that sometimes team members forget to talk about something they finished the day before, even if it is in the “In progress” column and has a DONE tag on it. But in this case it is easy to detect: if after the daily standup there are still DONE tags remaining, either they forgot to talk about it, or it was done by a team member that is absent that day (in that case, unless he went on holidays, teams normally wait for him to come back so as to not steal his achievement).

Can you quickly spot the finished tasks?

Can you quickly spot the DONE tasks?

Why blue tags?

The truth: no special reason. I just randomly chose a nice looking color. But then I found out that blue represents “good” in japanese, so -being these tags a Lean idea- this actually gave it some meaning. (For the curious: I learned this through a lengthy debate with Kohsuke Kawaguchi, the author of the Hudson CI engine. Hudson displays a blue screen instead of a green screen when the build is OK.) Blue also has very good contrast with yellow, making it easy to visualize finished tasks from afar, as you can see in the above picture. But there is no special reason for blue, and I have seen that some teams prefer using green for DONE.

Tags: , , ,