For those of you who could use a refresher, “Done Done” is based on knowing that a work item is capable of passing a set of agreed-to criteria between the stakeholders as well being capable of launching the very same work item into production. It was refreshing to hear a reference to the basic project management tenet, the Iron Triangle, and the concept of altering schedules/time (e.g. the Sprint length) to improve quality. Essentially, the common issue occurs when one person’s definition of done often doesn’t match someone else’s definition of done. When you can check off Done Done with everyone, that’s when you know you’re golden!

So at the end of the talk, I went up to Ken and asked: “What if you have the Product Owner/Manager constantly changing their requirements and definition-of-done-s on you in a start-up kind of environment?” To paraphrase, his response was clear and simple: it is what it is. The fault lies in both camps: on the team’s side, the PO isn’t being responsible by sticking to a clear-enough definition of done, and the team/ScrumMaster isn’t demanding a clear-enough definition in the first place. Both sides need to work something out, or else something or someone will break.

At the end of the day, you need to have clear requirements/user stories that also have clear (and preferably specific!) definitions of done (think acceptance criteria, functional/integration/unit tests, documentation, qualifying against industry standards, etc.). It also helps to have an overarching Sprint objective and Sprint-oriented definition of done. It’s the only way to get good expectation management and ultimately, good software. So slow down, talk it out, and get then it done!

I recently finished reading Dan Roam’s “The Back of the Napkin,” which is a great introductory and reference book on communicating with pictures.  I also spotted Seth Godin’s blog post commenting on this NYTimes post and its validity.  And last but not least, one of my favorite examples of multiple dimensions of data plotted on a single illustration is explained by Edward Tufte.  I mention all of these examples because it’s easy to make a bad picture, but not too hard to make a really good one.

My career is filled with all sorts of illustrations to prove a point. Whether it was as pedestrian as a pie chart, or a project timeline, or a business roadmap, illustrations allow someone to demonstrate a few things:

• That you’ve researched the problem at hand, and know what you’re talking about.
• That you can show variations of the issue (by drawing on top of the picture).
• That your analysis is sound.

There’s an inherent danger to pictures though, which is that sometimes they lend too much credence (as Godin points out above) to a weak analysis.  Godin points out that

“reviews never reflect the product, they reflect the passion people have for the product. As Jeff Bezos has pointed out again and again, most great products get 5 star and 1 star reviews. That makes sense… why would you be passionate enough about something that’s sort of ‘meh’ to bother writing a three star review?”

The point for any viewer of the illustration is to be skeptical of the data that underpins the picture.  Note that the NYTimes post relies on shaky data, whereas the Minard illustration is based on mostly secondhand (but reliable) accounts.  Both require at least two passes across the pictures shown, and the biggest difference is that the NYTimes post discredits itself, whereas Minard’s builds on itself.

Conclusion: Check to see if your pretty picture relies on not-so-pretty data.  If it does, don’t be lazy; find better data (i.e. garbage in, garbage out).