The question is what to do with the kanban cards after they were taken from your kanban board?
The simplest answer is to “throw them away”. Well, yes, sure, they are not needed anymore.
My colleagues from the next-door team (hello @tkowalcz!) have a different idea. The cards end up on a stake. Sweet, isn’t it?
And you? Do you have any creative/fun/useful idea of what to do with the finished cards? Please let me know!
When can you say that a task is done? This is an old topic but still important and still being discussed over and over by almost any team. Lately my team decided to come with a definition of done. This post presents our view on “what is ‘done’?”.
We tried to address every aspect of development – from coding & testing to documentation.
BTW. the order of things on our cheat sheet does not determine the order of work. For example TDD is more than welcomed so it is not like tests come after the code. Similarly javadocs don’t have to wait for the finishing of code activities.
The important thing is that our cheat sheet groups all things that should be done in one place.
Another issue is to realize that you will never be able put every detail on such cheat sheet. If you want it to be readable you need to choose words carefully. The point is, that everyone should follow the spirit of the law more than the letter of the law. If there is a point on “code quality check with Findbugs/PMD” it is rather obvious that you should use Codenarc instead, if you code Groovy. It is also obvious that often only some of these points are relevant for certain tasks (e.g. if your task is to write a user manual you won’t write integration tests for it, will you?). Common sense is always more important than strict rules.
So, here it goes – our definition of “done”. As you can see it is quite generic in nature but at the same time contains some things specific to our team (like issue tracker schizophrenia uh…). It also addresses some issues that we had earlier with our code (like poorly commented TODOs or lack of information sent to project partners about some significant changes).
These cheat sheets now hang on the two opposite walls (so everyone can see it) and we treat them seriously, which means that if a task is marked as “done” this really means it is DONE.
A very important aspect (at least from my point of view) is that the points were discussed, changed and rearranged by all team members. Even the graphical form of these cheat sheets was done together (in fact in 3 days we had 4 different versions hanging on the walls cause we believe that details are important, so we polished it till we all agree both with the content and with the form).
What surprised me (and made me very happy!) is that my teammates set some expectations regarding “done” tasks higher than I would!
Lets say few words on some points of the cheat sheet.
These are the tags that we put into comments to mark fragments of code that should be reworked (and later find them using IDE or Maven Taglist Plugin).
We decided to clear (that is to solve) all FIXMEs before the task can be marked as done. But we are less strict with TODO comments – as long as they say precisely what is to be done they are ok. So, a comment like
//TODO change it
is not permitted but
//TODO change variable name to be consistent with DAO naming conventions
is ok.
BTW., we are still discussing if it is ok to mark a task as “done” if the code still contains some TODO comments. The experience tells us that they tend to stay in the code forever (because of their low priority) which is bad. Ideally TODOs should also be removed. If we find it to be an issue, we will rethink our policy.
We don’t set any strict coverage percentage. We write a lot of “integration code” which is not easily tested with unit tests, and I don’t feel like we would gain anything by setting some high threshold here. What is expected of every team member is to have a look at the coverage report in order to find untested regions and think if it is sensible to write some tests that would cover them. That is all.
It is too early to say if it works because we introduced this “feature” a week ago (along with Kanban board, but this is another story).
Right now I can only say that it helps me to remember about all petty but important things that one have to do before moving on to another task. Will it have a same impact on the team? Will see about this soon (I plan to write some more on this in few weeks time).
Answering question asked by Jacek:
why did you think you’d have to formalize what’s DONE?
Did you notice teammates don’t follow your take on it or was it something else?
Few things here.
First, as mentioned before, we started to implement Kanban. So now we have this board with few columns and the last one is called “done”. Fine, the board looks nice, but what tasks can be moved to this last column? So we needed a definition of “done”.
The other reason is that we had some issues with our code like the thing with poorly commented TODOs (that no one knows right now what should be done there). Or issues related to “code ownership” which means that each person on the team knows his code and not much more. This will be hopefully addressed by peer reviews that now have to be done before a task is finished.
I also believe that such simple thing like preparing together such a cheat sheet is very good for team health. Definitely I would like to have more stuff done together in the nearest future (I guess that is the outcome of my recent interest in Agile and Kanban).
No links this time, because search will give you plenty of answers if you ask for definition of done or sth similar. Many of them really worth reading and quite inspiring. I would encourage you (and your team) to have a look at them before you start working on your own definition.
How do you define “done” within your team? Is it just a common sense of decency floating around in your heads, or do you have it “carved in the stone” somewhere like we do? Please comment.