Done. Really?


www.implementingscrum.com -- Cartoon -- November 27, 2006


Hi.For all those in the USA who “celebrated” Turkey Day last week, I hope you are enjoying your leftovers. Make sure to call it quits and either make soup or put them all in the trash by the end of this week. Food poisoning sucks. Know when to call it done.Which is a nice transition (if I do say so myself) to the topic of the comic strip this week.So, today I am going to talk about “Done.” Not how much to cook a turkey “done” — but how a team defines done in a Sprint. From experience working with many many many teams, I can tell you this — not one team has ever had the same definition.Why does defining “done” really even matter? Think about it this way… how will you ever know you are finished — really finished — and not at that eternal “we are 80-90% done” I see on many traditional waterfall projects.

“Mike. Are you kidding me? How hard can this really be?”

Here is an example I use when teaching a CSM (Certified ScrumMaster) Workshop:

I go around the room and ask each participant how long it will take them to read the latest Harry Potter book. Usually this is universal enough for people to use as an example.

The answers I get range from two or three hours to six or seven days to six months or more. Others — only a few — say, “Harry who?”

The round of answers (remember… this is a relatively “simple” answer) range from “Gasp… are you kidding me?” to actually opening a great facilitated discussion.

This simple exercise show the people in the workshop that such an easy task can have relatively different views of results.

Some people are speed readers, some people have kids to read it to, others pick it up once in a while, and others just don’t like reading.

Now, apply this to an agile software project using Scrum.

When a team is just starting out (let’s use an example of ex-waterfall-specialists). There are testers, developers, analysts, architects, and other roles on “the team.” At this point, they all associate themselves in that role (OK, not all, but most). At some point in the discussion, I send people to an article by Scott Ambler about Generalizing Specialists. Good stuff there. Read it if you are not familiar with this concept.

While facilitating the discussion about “done”, people usually get one of their first uncomfortable experiences using Agile. That is, having to commit to something. Ouch. This is hard, especially if some Chicken in the past has held their cajones over the fire about past dates being missed.

This is hard for teams to figure out. Really. And, the first time a team attempts to define “done” it will probably suck. And that is OK. Get enough of a definition of the word for the team to agree, and get started with the Sprint. Accept the fact that the definition will change from Sprint to Sprint. And that is OK. Inspect and adapt. Rinse and repeat as needed.

In reality, the team will soon figure out that the Product Owner has the final say as to what “done” really means. Using various tools like User Stories (by Mike Cohn), the team gets to negotiate the acceptance criteria of a story with the Product Owner. Notice this is not with the Chickens. If Chickens want to have a say as to the acceptance criteria of a story, they can hash it out (negotiate it) with the Product Owner outside of the team room.

The one voice the team turns to for the definition — and acceptance — of “done” for a Sprint is the role of the Product Owner.

Period.

End of story. For now, I am done.

Gotta run…

Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!

Originally Published:November 27, 2006

 


Comments

  1. cajon is a musical instrument – why would you want to burn that? Did you mean cojones? :))

Trackbacks

  1. […] Done. Really? Who’s Your Product Owner? Welcome to Oz. […]

  2. […] So what did I come away with?? As my friend Barrett says “I drank the Kool-Aid”.? I’m convinced that the techniques from Scrum (Agile) are the best way to do software. I’m also more convinced that ever that if you have a Scrum Master that can give the management and other stakeholders whatever they need, the team can be shielded from all the outside noise and with some guidance will figure out the best way for them to perform at a high level.? We currently do some things core to Scrum at my current job which is great.? The big area where I would like to see improvement is getting the team to a point where they are focused on a goal and constantly looking for ways to do their job more effectively.? Things like having a definition of Done, Sprint Reviews (Demos), and Sprint Retrospectives. I even learned things not part of Scrum, but part of being able to work on teams and communicate effectively with team members and management. I learned how to give and receive feedback and how to deal with certain team dysfunctions.? As I slowly migrate into a Scrum Master role on my team, I want to introduce (or in many cases, re-introduce) techniques that I think the team can handle, and continue inspecting-and-adapting to improve our performance. […]

  3. […] And it goes on and on and on…. with teams never getting to “Done.” […]

  4. Scrum – Definition of Done…

    DONE Are we there yet? Definition of Done (DOD) The definition of done is a team defined state of completeness.  It’s the team’s checklist to ensure that a piece of work (story) is complete…….

  5. […] And it goes on and on and on…. with teams never getting to “Done.” […]

  6. Scrum – Definition of Done…

    Definition of Done (DOD) \ Are we there yet? The definition of done is a team defined state of completeness.  It’s the team’s checklist to ensure that a piece of work (story) is complete…….

Speak Your Mind

*