When is a new feature "done"?

A feature is done when the client has been told it’s done and they’re able to independently confirm that it’s done. Never before!

Background: I was introduced to this concept from a Manager Tools podcast, shortly after I was (correctly) chewed out by a client when reporting something was "done and ready to go up to staging."

When is a feature NOT done?

  • Not when it's been committed to git
  • Not when the feature branch is merged to master
  • Not when it goes on staging
  • Not when it passes internal testing
  • Not when it's sitting on production
  • Not when the ticket is closed
  • Not when you start your next task/sprint
  • Not when you bill for it

What if I don’t have a client?

There’s always a client, because you are always accountable to someone. Other words for client include:

  • Product owner
  • Boss
  • Mentor
  • Peer group

Do I need to show the client the feature?

It depends on the type of work being completed:

  • If the work is a feature that forces a new decision (e.g. producing a logo mockup that needs to be approved) then yes, the client needs to see the work as part of communicating it is done.
  • If the work is a feature that came from a previous decision (e.g. add a new column to a report) then no, the client doesn’t need to see the work, because they can verify later.

What is the best way to tell a client?

In writing—but not inside your project management software. In writing means:

  • An agenda
  • An email
  • An emailed agenda (heh)

The habit of writing what is done in an agenda comes with benefits:

  1. Putting together the list forces you to update and prune the tickets in your project management app.
  2. Providing the list in writing creates a history that is searchable in email inboxes and shared drives.
  3. An agenda means a meeting, which forces accountability.

Isn’t a meeting to report what’s done a waste of time?

Maybe!

If the agenda only contains completed work that does not force a new decision, and there are no other decisions to be made in the meeting, then the agenda should go out as an email update with a request that the meeting be skipped.

Because I run my meetings on a set repeating rhythm, a skipped meeting isn’t a big deal—we will be talking again soon anyways. I wouldn’t skip a one-off meeting.

This email acts as a regular touch point to keep the client connected to the project, and invites them to share anything from their side that you need to know.

I’ve never had to skip two meetings back to back due to this.

Why can’t a client sign in to JIRA/Asana/etc to see what is done?

This pushes the responsibility of tracking progress onto the client.

It gets a non-expert all up in your process. They’ll add new features, reprioritize items, and ask for updates on individual tasks. This is toxic for the team and interferes with the project manager’s job.

Control the interaction and let the client contribute through a structured meeting.

What does the list of done features look like?

  • Create a heading in your agenda called “DONE”.
  • Under that heading, create an ordered list. Each list item is the title of a completed feature.
  • These titles should come directly from your project management app. Copy pasta.
  • Links to the feature’s ticket, if necessary (usually not).
  • Extra information (notes, screenshots, etc) as sub items of the parent feature.

Simple, clean, easy to read.

How long should it take to compile the list?

If you’re already running a well organized project, and update the client on a weekly or bi-weekly basis, it will take 5-10 minutes to prepare.