Agile

Kanban: make the most of those post-it notes!

Just a short post about all the information you can squeeze onto a humble post-it note …

ticket

I don’t like to overload a new team with too many concepts at once, so when a board is relatively new, I usually start with the standard card information:

  •  The description: single words are rarely a description. Everyone using the board should be able to understand what work is being done, not just the person who wrote it. Some people do have problems writing short and pithy descriptions in a legible script – using a finer felt-tip pen normally does the trick. 🙂
  • The owner of the work-item – if I’m working on this topic and I have a question who should I ask?
  • The ticket number – the majority of physical boards that I’ve been involved in have had electronic ticketing systems in the background. By putting the JIRA/Redmine/TFS/etc. number on the work item more details can be extracted from the ticketing system if needs be.
  • The input/start date: when was this work chosen for the board? Not when it was started, but when was it added to the next/selected/input column.
  • The end/finished date: when was the work considered finished. Depending on the team that your working with, this could be when the customer actually gets the finished work or when the team actually stops working on the work.

Then, as the board develops, there are several options that can add more value – depending on the team size, the work they are doing and the problems that need addressing:

  • Avatars: I have to admit, that I’m a fan of avatars. With smaller teams you can usually remember who’s doing what, but as soon as there are more than four or five people involved, avatars are a great way to track who’s doing what. Personally I prefer photos to symbols, but I understand that some people don’t like their picture on the wall – on some boards we have a mix of photos and furry animals, star signs, cartoon characters, etc.
  • Blockers: some of the most important information that you can glean from a physical board! Really valuable blockers should record 3 pieces of information: what was the cause of the blocker, when did it start and when did it end. With this information you can analyse the cause of blockers as well as the time that they cost – the basis for real improvement!
  • Change Requests: how often did the customer change their mind while the work was already in progress? It’s enough to put a dot on the card to note a change request. Over time you can track how many items have had change requests and whether they indicate a deeper requirements problem.
  • Quality issues: by this I mean a lot of back and forth between test and development. So if a regular answer to the question: „This item has been in test for quite a while, is something stopping the testing?“ is „We had to send it back to development for bug-fixing“, then it’s probably time to start tracking quality issues. Again this can be tracked by adding a dot to the card – just don’t mix them up with change requests if you’re tracking them as well! Similar to the change requests, root cause analysis is great at determining why there are quality issues.

Obviously there is more information that you can add to the tickets – and what’s important will depend on the people using the board and the challenges that they’re facing. Also, there’s only so much space on a post-it note 😉

Passende Artikel

Kommentare gesperrt.