Here’s another post I made about defining done for a project. This goes along with my previous post where I talked about my challenge to myself about writing a song and recording it every week. My definition of done for that experiment was:
- Song was written with an intro, verse(s), chorus(s), and at least an outro. Bridges and solos were optional.
- Song had some decent orchestration. Guitar, bass, drums.
- Song was recorded at mixed down so I could share it.
Pretty loose, but it was easy enough for me to determine if I could consider it done. After all there was a deadline each week. Well, check out the stuff below for more on how I handle projects.
Grilling. I love it. I suck at it. I may be the one guy on the planet that didn’t get the grilling gene. The concept is simple, the act of grilling that is, but alas I just don’t get it. Chicken either ends up completely charred or soggy in the middle. Burgers bloody or over cooked. Steaks rubbery or tough. I just can’t seem to get it right. On the occasion I do get it right, it usually involves me checking every 20 seconds by slicing a chunk out of whatever I’m cooking to see if it is done. By the end, the item vaguely resembles what it is supposed to look like. This is ok if I’m going to cut it into smallish pieces for a salad…not so ok if it will be served at one of our little outdoor gatherings. It’s all about knowing when it’s done. See what I did there?
Projects are a little like grilling. If you leave them going too long they get tough and add little value. If you take them off too soon you get salmonella. Ok, so that was a stretch, but like grilling you need to know what you’re going toward. If you know you like your burgers medium then you want to get them off the grill when there is still a little pink in the middle. If you are shooting for well done, you want to make sure all the pink is gone, but that you haven’t achieved the black shell I often get. The point is that you know what you are driving toward. This is what done looks like for a project.
You should understand conceptually what you are going to see when the project is done. What are the things you will be able to do? How will the system react? There are many techniques to visualize what the project will look like when it is done.
Story mapping is a great one. David Hussman has a great video on Story Mapping on his site if you’re interested in learning the particulars. http://www.devjam.com/coaching/cutting-an-agile-groove/
Inception Decks are something we use at MSIS a lot. It’s somewhere around 20 slides that helps you navigate most of the questions you need to think about to loosely define the scope of the project without being so rigid as to not give you some flexibility. If you work for the University of Michigan, you can check out our Inception Deck template here: MAP Inception Template. If you’re not an employee, you can see the inspiration for ours here: agile warrior. We added some items that work for us like Transition to Operations, and Non-functional type requirements.
When we are working on the Inception Deck we do our best to break the project up into logical chunks and estimate them at a very high level based on previous experience. This gives us our target.
A3s, known for the larger paper size, were borne out of Toyota. The idea is to write down the problem, an analysis of the problem, proposed corrective actions and a plan of action written on one A3 sized sheet of paper. A3s are common in Lean communities.
There are many other ways of understanding what the end state of the project is, but the one thing all of the techniques above have is that they foster communication. In Agile, there are many practices that foster collaboration and further discussions. Story Mapping involves the team standing around a table, mapping out thin slices of functionality. The Inception Deck requires that the team work with the Product Owner to understand what is really needed. An A3 gets completed by a team talking about what the real problem is, possible solutions, and then creating some actions. The most important part of any of these is to have discussions, to understand each other, and then to plan the next steps. Our technique of choice is the Inception Deck.
If we don’t have a concept of what done looks like, the burn up charts we talked about for Keys 7 and 8 become meaningless. Even worse, if we don’t know what done looks like the project will often labor on and on and on and on…dumping money and features into the Island of Misfit Projects Black Hole.
At some point we have to translate done into a certain amount of features or stories. If we have a complete backlog it’s easy to see when done will be achieved. You don’t typically start off a project with a complete backlog though so there is a period where the backlog grows based on what you’re learning. It often takes several iterations until you have the main features described in the backlog as stories or epics (a collection of stories that are related). Many Scrum teams will use the concept of an Iteration 0 to help flesh some of these things out.
We’re going to leave this subject for a bit and return to it when we talk about stories. In that case we will be looking at “done” at a different, equally important level.
For the record, I’ll have my steak medium.