The definition of done

From large to small, from projects to issues, a team needs to define when they are considered done.

From large to small, from projects to issues, a team needs to define when they are considered done.
This decision differs from team to team, some have steps to done, others just one state. Even the words used in your issue tracker reflect your choices: what does ‘fixed’ mean, what is ‘closed’ used for…
Even some practices like test driven development define a state of done: the code is done if all tests are green and it is refactored.

What’s your definition of done?

Let’s take a look at some examples:

  • tests are green and code is refactored
  • QA says ok
  • customer/stakeholder/product owner accepts the issue
  • developer thinks the code reflects the description in the issue
  • a predefined spec, maybe even with an acceptance test, is fulfilled
  • no bugs were found while clicking through
  • the code is merged with the master branch
  • the continuous integration tool has found no errors

The problem with this ‘definition of done’s is that either they look for an external person to accept by their opinion/guideline or concentrate on some output. But the people needing the software do not want the software in its own regard. They want to reach a goal through the software. The software is a mean to an end: their goals. Without defining the goals and needs beforehand you are either doomed to guess them and are at the mercy of arbitariness (from your point of view) or concentrate on some measurable output like code, tests or a completed feature.

Defining what the user wants to do with this new feature or project should be the first thing in a project right after the initial introductions. Who will use the app or the feature? (the intended audience, the users) What do they expect from it? (the benefits) What goal do they want to reach?
With this questions and answers you have a target. After completing the issues or project you can see if the target has been reached, if the goals are met. It might be the same with an acceptance process from a stakeholder but here you know the target beforehand not after.

Summary of the Schneide Dev Brunch at 2013-03-03

If you couldn’t attend the Schneide Dev Brunch in March 2013, here are the main topics we discussed summarized as good as I remember them.

brunch64-borderedYes, you’ve read it right in the title. The Dev Brunch I want to summarize now is over two month ago. The long delay can only partially be explained by several prolonged periods of illness on my side. So this will be a rather crisp summary, because all the lively details have probably vanished by now. But let me start by explaining what the Dev Brunch is:
The Dev Brunch is a regular brunch on a sunday, only that all attendees want to talk about software development and various other topics. If you bring a software-related topic along with your food, everyone has something to share. This brunch was very well-attended, but we still managed to sit around our main table. Let’s have a look at the main topics we discussed:

XFD presentation

In a presentation of a large german software company, our Extreme Feedback Devices were thoroughly mentioned. We found it noteworthy enough to mention it here.

Industrial Logic’s XP Playing Cards

This is just a deck of playing cards, but not the usual one. One hundred different cards with problems, solutions and values wait for you to make up some game rules and start to play. The inventors have collected a list of possible games on their website. It leads to hilarious results if you just distribute some cards in a group of developers (as we did on the brunch) and start with a problem. Soon enough, your discussion will lead you to the most unexpected topics. We ended with the “Power Distance Index“, but I have no recollection how we got there. These cards are a great facilitator to start technical discussions. They seem to be non-available now, sadly.

Distributed SCRUM

A short report on applying SCRUM to a multi-site team, using desktop sharing and video chat software. The project landscape is driven by an adaption of “scrum of scrums”. I cannot dive into details anymore, but these reports are a great reason to really attend the brunch instead of just reading the summary. The video chat meetings were crucial for team-building, but very time-consuming and wearying due to timezone reasons.

SCRUM User Group Karlsruhe

Speaking of SCRUM, there is a SCRUM User Group in our city, Karlsruhe in Germany. It might not be the biggest user group ever, but one attendant of our brunch reported that all participants are “socially very pleasing”. There are very interesting presentations or gatherings for specific topics. If you have to deal with SCRUM, this should be on your agends.


We had a prolonged talk about retrospectives and how to apply them. Most retrospective activities tend to be formalized (like “cards and priorities”) and lose effectiveness due to the “comfort aspect”. A hypothesis during the talks was that when moderation isn’t necessary anymore, its more likely to be a negative smell. We talked about moderated vs. non-moderated retrospectives quite a bit, also exploring the question what role should/could be moderator and why. The “Happiness Metric” was mentioned, specifically its application by the swedish company Crisp, as described by Henrik Kniberg. Some sources of ideas for retrospectives were also mentioned: the Facilitator Gathering or some noteworthy books that I forgot to write down (sorry! Please ask for them in the comments).

Internal facilitator

We also discussed some problems that “internal” facilitators face day-to-day. Internal facilitators work within the team they try to facilitate.

Presentation about acceptance testing by Uncle Bob

A big event in February this year were the workshops and the presentation with Robert C. Martin about testing. His talk presented Fitnesse in the context of acceptance testing. There was some confusion about the amount of available seats, so most of us didn’t attend (because we weren’t able to register beforehands). Some of our participants were there, nonetheless and found the presentation worthwile. Only the usual pattern of Uncle Bob’s presentation lacked some virtue this time, but this can easily explained with the flu. Here’s an external summary of the event. Check out the comment section for potential first-hand accounts.

Definition of test types

In the wake of our talk about Uncle Bob’s presentation, we discussed different test categorization schemes. We’ve invented our own, but there is also a widely used definition from the International Software Testing Qualifications Board. We didn’t dive deep into this topic, so lets say it’s still open for discussion.

Book about money counterfeiter

Somehow, I’ve written down a notice about a german book about a famous money counterfeiter, Jürgen Kuhl: “Blütenträume”. This talented artist drew dollar notes by hand so perfectly that even experts couldn’t tell them apart. Regrettably, I don’t remember the context anymore. It might have something to do with Giesecke & Devrient, a manufacturer of money printing machines. But even then, I don’t remember what that context was about.

Traceability of software artifacts

Our last topic circled around the question how software artifacts are registered and traced in our practice. The interesting part of this question is the ability to make connections between different artifacts, like an automatic report about what existing features are tangented by a change and should be tested again (if manual tests are necessary). Or you want to record the specifics of your test environment alongside your tests. Perhaps you are interested in the relation between features and their accompanying tests. The easiest connection can be made between a change (commit) and the issue it belongs to. But changes without issue (like almost all refactorings) are problematic still. It was an interesting discussion with a lot input to think about.


One thing I’ve learnt from this Dev Brunch is that it isn’t enough to write down some notes and try to remember the details some weeks later. The summaries have to be written in a timely manner. I didn’t succeed with it this time and try to blame it on my lack of health. I promise a better summary next time. The worst part is that I know that I’ve forgotten a lot of important or interesting details (like a youtube channel about ideas – please provide the link in the comment section, Martin!) but cannot recreate the memories.

As usual, the Dev Brunch contained a lot more chatter and talk than listed here. The high number of attendees makes for an unique experience every time. We are looking forward to the next Dev Brunch at the Softwareschneiderei. And as always, we are open for guests and future regulars. Just drop us a notice and we’ll invite you over next time.

Follow-up to our Dev Brunch October 2010

A follow-up to our October 2010 Dev Brunch, summarizing the talks and providing bonus material.

Last Sunday , we held our Dev Brunch for October 2010. We gathered inside (no more roof garden sessions for this year) and had a good time with lots of chatter besides the topics listed below.

The Dev Brunch

If you want to know more about the meaning of the term “Dev Brunch” or how we implement it, have a look at the follow-up posting of the brunch in October 2009. We continue to allow presence over topics. Our topics for the brunch were:

  • Beyond Scrum – The first-hand tale of a local team that transformed their process to do Scrum and failed for several reasons. They finally admitted failure and search for alternatives since. Great stories of mistakes you don’t have to make yourself to learn the lessons now. We decided to transform at least some aspects of the whole story in an essay, as it’s too valuable to not be published.
  • Code Camp experiences – We already blogged about it, but this talk gave away more details and more insight from the trainer’s perspective. The speaker guided a two-day developer code camp in the spirit of code retreats with an experienced team and draw several conclusions from the event. In short: It’s well worth the time and you will see your team differently afterwards. Other attendees added their experiences with team games that reveal social structures and behaviour even quicker.
  • Local dev gossip – Yes, this is a rather unusual topic for the offical topic list, but we exchanged so much gossip talk this time that it qualifies as a topic on its own behalf. The best summarization of this topic is that there’s a lot of moving around in the local developer community, at least from our point of view. We look forward to a very exciting next year.

As there was no dev brunch in September (due to several reasons), we needed to talk about the news and rumours of two months at once. And there are a lot of things going on around here in the moment. A great brunch with lots of useful information.

Follow-up to our Dev Brunch April 2010

A follow-up to our April 2010 Dev Brunch, summarizing the talks and providing bonus material.

Last sunday, we held our Dev Brunch for April 2010. It was the start of the open air season, introducing our new office roof garden. We brunched under a clear, sunny sky (no clouds, even no vapor trails from airplanes, as they aren’t allowed to fly because of some distant volcano ash emission) and talked about agile processes and books. A major part of the brunch was graded as “informal chatter”, just as it should be like.

The Dev Brunch

If you want to know more about the meaning of the term “Dev Brunch” or how we implement it, have a look at the follow-up posting of the brunch in October 2009. We continue to allow presence over topics. Our topics for the brunch were:

  • Agile life planning – Your software development daily routine is to incrementally build software from a backlog and release it after a fixed timebox. What might happen if you transfer this process to your private life (often called “real life”)? You’ll release a week’s life every week and have a week planning meeting on sunday, filling your week/sprint backlog with the most important items of your life’s backlog. Telling from this first hand experience of about a year, it works exceptionally well, improving the leisure time quality and making “progress” visible even at harder times. The only remaining question is who acts as the product owner.
  • Converting to Scrum – First hand experience of a team that, after years of “alarm call”-style development, successfully implemented Scrum as their primary process. The effects were at least less overtime, improved progress tracking, improved code quality (though Scrum is  only a management process!) and less pressure in the project. The customer even adjusted their wording when talking about new features: “next sprint” instead of “immediately, now”. The implemented process isn’t vanilla Scrum, but works nevertheless.
  • Defending Continuous Integration – What if, after an initial phase of excitement over the new tool, the continuous integration server really reveals flaws in your project? There seems to be the tendency to kill the messenger: Shut down the CI server and everything’s fine again. This talk was about the reasoning of both sides and some basic insights gained about machine sharing. Tip of the talk: Reserve your CI server exclusively for this task.
  • Book recommendations – A random collection of technical books read in the last half year, presented with a short summary and personal rating. Titles included were Coders At Work, Founders At Work, 97 Things Every Software Architect Should Know, 97 Things Every Project Manager Should Know, 97 Things Every Programmer Should Know, Hiring the Best Knowledge Workers, Techies & Nerds and Manage Your Project Portfolio. Yes, there are some patterns visible in the book titles. And it’s a good idea to keep some checklist of read articles for most of these books.
  • Dreyfus Model of Skill Acquisition – The Dreyfus Model differentiates five to six different stages of learning some arbitrary skill. It makes assumptions how the members of the stages work, how they process feedback information and what they need to get better. See the comment section for more information and bonus material.

As usual, the topics ranged from first-hand experiences to literature research. For additional information, check out the comment sections. Comments and resources might be in german language.

Retropection of the brunch

Holding the brunch in the bright morning sun, surrounded by rooftops and birds, really is a huge gain for the ambience factor. We even found a solution to produce fresh coffee up there. This will be a fun summer for the Dev Brunch.

Follow-up to our Dev Brunch February 2010

A follow-up to our February 2010 Dev Brunch, summarizing the talks and providing bonus material.

Today, we held our second Dev Brunch for 2010. It was the first one in the new office, with some packing cases still around. The brunch had some interesting topics, most of them small and focussed. We discussed if the topics should be announced beforehands to avoid collision, but defined these collisions as enrichments rather than duplications.

The Dev Brunch

If you want to know more about the meaning of the term “Dev Brunch” or how we implement it, have a look at the follow-up posting of the brunch in October 2009. This time, we didn’t urge all participants to bring their own topic. Presence is more important than topic.

  • Scrum adventure book review – There are lots of book on the Scrum project management process. But the one called “Geschichten vom Scrum” (sorry, it’s a german book!) will teach you all the basics and some advanced practical topics of Scrum while telling you the fairy tale of a kingdom haunted by dragons. By following a group of common fairy tale characters in their quest to build a dragon trap the Scrum way, you’ll learn a great share of real world Scrum and still be entertained. You might compare this book to Tom DeMarco’s “The Deadline”, a novel about general project management.
  • What is the Google Web Toolkit? – Based on the learning from the presentation of the Karlsruhe Java User Group (JUG-KA), we skipped through the slides to get to know the Google Web Toolkit (GWT) framework. Advanced topics were discussed in the next talk.
  • First hand experience with GWT – We talked about the sweet spots and pain points of Google Web Toolkit, based on the experiences in a real project. This was very helpful to sort out the marketing promises from the definite advantages. While the browser doesn’t affect the developer anymore, the separation of client (browser) and server will still leak through.
  • First impressions of the Lift framework – The way to go with web application development in Scala is Lift. It’s a framework borrowing the best from “Seaside, Rails, Django and Wicket” and combining it with Scala and the whole Java ecosystem. While this talk was just a teaser, it already looked promising.

As usual, the topics ranged from first-hand experiences to literature research or summaries of recently attended presentations. You can check out the comments for additional resources, but they may be in german language.

Retrospection of the brunch

It’s right to grant access to “non-topics”. This will lower the barrier for occasional guests while they are valuable for their experiences and insights. This brunch was enriched by yet another topic collision, which is the perfect situation for a more in-depth discussion.