This series is about how to do stuff right by explaining why we do those things we do. If you do, and get the wrong results, you might be doing it wrong.
Last time, we talked about the Definition of Done. We use is as vision of where we want to be at the end of the iteration. The question is: What happens if we’re not completely done?
The truth is if we’re using the Definition of Done as a measurement, rather than a guiding light, we’ll often be disappointed. And by “we” I mean the business side.
Because, if you remember, the DoD is one more tool to build trust between the two sides, business and development. It also helps to clear up assumptions, get specific examples and make sure everyone on the same page.
At first.
But then things happen. A lot of things can happen inside the iteration. Which may lead to some surprises at the end.
Miscommunication – While the DoD maybe clear in the beginning, we still find things out as we work. Sometimes we don’t get answers or decide the wrong way, by ourselves or in our group. The result is a difference between what was expected and what was built.
Change of heart/mind/requirements – People change their mind all the time. New information comes in, priorities change, and suddenly what we know “now” is different than the original DoD. Sometime the DoD gets redefined, sometimes it’s just talked about, and then at the end people get surprised.
Feedback – Part of the new information comes from using the product. If an early preview is available, it may change the direction of what we’re going to build by the end of the iteration. That’s a good thing for the people in the loop. For others – not so much.
Things take longer – They always do ,and what that happens, we need to trim down the content. Once more, the new DoD may not be clear to all, maybe not updated, and the idea of what is Done gets more confusing.
And my favorite functionality is done, but quality is not good enough – That happens a lot. Like, “Done with two open bugs”.
You need to remember: There is always an expectation that “Done” means no bugs. No matter how much experience everyone involved has. Any bugs (no matter how small or insignificant), cause some erosion of trust. They shouldn’t, but they do.
Ok, now what?
So now we’re left with a question: What do we do? Is it done? Is there a new “done with bugs” status? Do we call the current ticket done and open a new ticket for the next iteration?
Let’s start with what you shouldn’t do: Don’t call it done if it’s obviously not. That includes “dev done” but not tested. Or half-tested. Or coded, but no unit tests. Or not reviewed by product. It’s not done.
The next thing is decide what to do: Stop working on it, continue working and fix it, redefine what done is, decide how much you’re going to invest in completing something that has value. Then communicate. Everyone should be on the same page about what still needs to be done, and what the end result would look like.
It could be that you’re still aiming to release the story as-is (with the open bugs, or less scope). Maybe quality is not important right now. Or it’s good enough by your standards (again, if your standards include code review, but it wasn’t reviewed, it’s not done).
Done should mean ready to ship (or preferably shipped). That should be the measuring stick. It may be you intend to fix the two open bugs in the next iteration. But that means you’re not done yet.
Can I have some bureaucracy too?
So that the deciding part. But should we mark the story done? Open a new story? Or bug? Or task? How do we track the leftovers?
Good question. Here’s a better one: why do we need to track the leftovers for?
Apart from closure and accomplishment, declaring a story done is important for measuring velocity. There’s a whole “You’re doing it wrong” post or two dedicated to velocity coming up, but for now the important thing is the only thing that knowing when a story is done, is to help you with future projection.
The points of how many stories per iteration are done or not don’t really matter. (I promise to discuss this on the velocity post). What matters is how long the work actually took. This is what you need to track.
One more thing: Don’t compare how much it took compared to the initial estimations. The only thing you can learn from that is how much you suck at estimations, and I can tell you that anyways.
Brilliant minds have suggested the new “Done, done, done” definition as opposed to regular “Done” that is really not. But really, there is only one kind of Done, and we recognize it when we see it.
| Reference: | You’re doing it wrong: Done-Done from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
