Posts Tagged “definition of done”

The two-headed, three-armed beast is slain. (See my previous post if you don’t get this reference.)

An interesting question arose the week before we began UAT. How do we decide when UAT is done?

There were several proposed answers to this.

  • When all the test cases pass.
  • When there are no open issues remaining.
  • When there are no critical open issues remaining.

Or, my personal favorite:

  • Starting Friday afternoon, put all the VPs in a room and let them decide. Repeat on a daily basis until the VPs all decide we’re done.

Isn’t that a lot like how they select the pope?

I pulled a page from agile (at least, from my book on agile) for the answer to this:

UAT is done when the users say they can and will begin using the delivered product in their daily work.

Sometimes I earn my pay. And sometimes people even listen to me.

UAT lumbered along for four weeks as the PM reported daily progress against existing issues and the new issues that had been uncovered. The users regularly said “it’s getting closer but we can’t trust the data yet.”

Sometimes things work out just about right – and this was one of those times. When it was clear things weren’t going according to plan, everyone ignored the arbitrary deadline. No one pushed the users to accept a deliverable that made them uncomfortable. The users and the team, meanwhile, communicated meaningful status on a daily basis. Everyone agreed on the goal, and could sense whether we were moving toward or away from that goal.

Finally, earlier this week, we got the word: “We’re ready to use it. UAT is over. And here’s the three things that still need to be resolved in a follow-up release.”

Again, the way it should be. I know there are sound reasons why you cannot always let users decide when they are ready to accept the delivered product and end UAT, but everything goes so much smoother when you can.

Comments 1 Comment »

Once you realize that you’ve put yourself in a deep hole, please please please stop digging.

In the past few years I’ve been involved or drug into countless discussions about teams that have incurred technical debt. And I must admit to initiating more than a few of these discussion myself. The funny thing is that the theme of these discussion is almost always the same: “How do we get the business and upper management to understand that this system really will implode if we don’t start prioritizing some of this debt.”

I cannot, right now, recall a single time when the conversation’s theme was: “How do we stop digging?” I admit, that must have occurred … at least once … but I cannot recall it right now.

Yes, there are real business decisions that cause us to incur technical debt. Technical debt often results from a prioritization ethos that focuses on low-estimate patches and sidelines large or even mid-sized features. It can also result from a focus on revenue generation that entirely ignores cost savings. For example, imposing routine manual activities that may be better handled by simple ad-hoc reporting systems or crud maintenance screens.

This said, I’ve never seen a technical debt backlog that did not also include–or was even overweight with:

  1. Gaping holes in test coverage,
  2. Swaths of documentation-free code,
  3. Opaque data structures, and
  4. Duplicate methods and unnecessarily complex design.

All these issues (and more) result from team-level decisions, not business prioritization. Two months into a project these decisions cannot be undone without business consent. Moving forward, however, the team can stop making these decisions. Instead of decrying the existing technical debt, the team can first focus on disciplined processes that will reduce (if not stop) the team’s decent into further technical debt.

Clarifying and enforcing the team’s definition of done is the best way I know to quickly reduce the team’s creation of technical debt. Specifically, the team needs to come to an agreement about the documentation, testing, refactoring, and other activities that must be complete before a task, user story or feature can be declared done. The team and its individual members must also be mindful to account for these activities during estimation, thus ensuring that there is time to do things right the first time.

Simply put, the team needs to start to tackle technical debt by first enforcing internal discipline and best practices. Once these are established, the team may be surprised to find itself on much more favorable ground when it comes to tackling business-generated technical debt.

Comments 1 Comment »