Suggested Topics for Definition of Done Discussion

Ken Schwaber and the rest of us advocate paying attention to what “done” means for a Product Backlog Item (PBIs, or “stories”). For a lot of programmers (like me), “done” often means “It works on my workstation!” The Scrum Master is charged with advocating a “done” that includes everything else needed to build a potentially-shippable product increment. So we need a cross-functional team.

To avoid nasty surprises at the Sprint Review Meeting, I’d suggest initially attaching a definition of done to each PBI during the estimation process. Don’t be surprised if the estimate more than doubles — better to find out now than have the illusion of progress and an unpredictable ship date.

If you’re using cards, write the definition of done on the cards. I prefer the larger index cards for teams just starting out. If you’re using ScrumWorks, write the definition of done in the “description” field — that’s what it’s for. Remember to check this during the Sprint Review Meeting. 98% done rounds to zero.

Scrum, a generalized framework rather than a defined process, doesn’t prescribe a particular definition of done. We expect you to use an inspect-and-adapt process to discover the appropriate definition for your unique circumstances.

However, reading this may save you a couple iterations because the same kinds of things come up a lot. I’ve listed some things I recommend talking about as you inspect and adapt your way toward your best definition of done. You may not need all the listed things in the beginning. I’ve discovered setting the bar too high initially can make the team feel it’s pedaling a bicycle uphill in the wrong gear. But talking about these things is better than unpleasant surprises at the end.

  1. Business Criteria often forgotten
    • degree of feature richness
    • usability
    • performance
    • timing
    • scalability
    • reliability
    • interoperability (e.g. supported browsers)
    • in production or not
    • cross-cutting concerns
      • compliance with corporate integration needs
      • external regulations (i.e. legal)
    • whether/when regression failures allowable
  2. Example engineering criteria to prevent Technical Debt
    • pair programming, code/design review
    • manual test
    • automated test coverage
      • unit tests
      • system tests
        • prefer same language (e.g. Java, if your production code is in Java, not brittle capture/playback or proprietary scripting languages)
    • refactoring
      • changing internals without changing behavior. Incrementally remove duplicate code, business logic in your presentation layer (JHTML, JSPs, etc.), complex conditional logic, poor naming, obsolete libraries….


Michael James
Software Process Mentor
Danube Technologies, Inc.

For a general description of Scrum, see the Scrum Reference Card.
For more about the Scrum Master role, see The Example Scrum Master’s Checklist.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
2 comments on “Suggested Topics for Definition of Done Discussion
  1. lina says:

    Hi Michael,

    I love reading your article. It is very valuable info. Thank you.

    I have questions.How to create and prioritize PBI for ERP System Implementation? Usually ERP implementation, we can not create PBI that satisfies INVEST criteria.

    Thank you

  2. Juan says:

    That point Lina, is something I´ve been asking for myself. Is it Scrum the ideal choice for personalize products such as ERPs at the implementation level? If you focus on statistics, Scrum Projects finishes on time and without loss 48% of times, meanwhile waterfall ones, are successful just 17% to 18%, so, if you add Scrum and Waterfall, your chances of sucess are around 66%. It means that you should determine which approach to use. Maybe sometimes there will be other approach instead those two. One solution I have been dealing with is to use spyral prototyping and using a vertical of features, that´s to tell who can manage a specific story no matter if its tasks are dependent or not. I know it sounds contradictory with scrum principles but you can divide the implementation Project in deliverables like Sprints, then use cells or isles of specific stories, rearrange the goals for the deliverable and let programmers to be in charge of tasks that are pat of that cycle. In such way if something is not complete, you can show something of it and be clear for which cycle can be done at 100%.

Leave a Reply

Your email address will not be published. Required fields are marked *




You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>