0
(0)

What’s one thing YOU could do as a ScrumMaster to improve your team’s reliability, quality, and productivity? Read on and find out…

One of the most effective tools that can be employed to improve product quality is the creation of a “Definition of DONE” or DoD. The DoD can be used by the team to get everyone on the team on the same page in terms of what has to be done in order to call a product backlog item DONE. The DoD is much more than just, “it works” or “it’s finished” and should include all of the regulatory, administrative, and logistical elements required by the product. For example, for a software product, your team’s DoD might include the following:

  1. All specifications have been updated, reviewed, and approved.
  2. All code has been reviewed.
  3. The software is in an integration environment and completely tested.

Let’s say your team builds marketing materials instead of software (yep, you can use Scrum for that), your team’s DoD might include the following:

  1. All brand elements (color, font, etc) has been verified.
  2. Legal department has approved all content.

See how it works?

USING THE DEFINITION OF DONE

During the Sprint, the Definition of DONE should be considered by the developers on the team while the solution is built, while estimating the backlog item, and particularly when saying to the Product Owner, “Hey, this product backlog item is done.” Developers are responsible for ensuring that the DoD is achieved before they say that a product backlog item is complete. Likewise, the Product Owner is encouraged to verify Doneness should there be any doubt.

BUILDING THE DEFINITION OF DONE

When building the DONEness Definition, I can offer you three tips:

  1. Start with what’s already required by your organization’s standards of coding, documentation, database construction, etc. Then add anything required by the product that you’re building. Then sit down with your team and see what they want to add to the definition to finish it.
  2. It won’t be complete. Ever. Things change all the time. Don’t go for perfect, go for good enough and improve it as you go.
  3. Always remember that the DoD is OWNED by your team…not you. Creating or modifying a DoD is something that your team should be driving.

PRODUCT QUALITY

By using the DoD properly, you can almost immediately improve product quality. Should you continue to experience new defect detection after the Sprint, you should try to figure out what might be missing from the Definition of DONE. Remember, the definition isn’t written in stone — check it every three months or so and see if it needs to be updated.

AN EXAMPLE OF DONENESS

  • The Product Owner likes it.
  • It has been integrated with the rest of the product and nothing else broke.
  • All tests (unit, functional, integration, performance, security) ran successfully.
  • All artifacts are properly checked-in.
  • All coding standards have been followed.
  • All design standards have been followed.
  • All documents and specifications have been updated.
  • All naming standards for all artifacts (code, tests, documents, etc.) have been followed.
  • All regulatory requirements have been followed (i.e., requirements specifications, requirements traceability matrices, etc.)

FOR MORE

Click here for DONENESS on a Page.

FEATURED RESOURCE:

FEATURED RESOURCE:

Guide to Defining DONEness

Swipe this FREE DOWNLOAD and define your quality outcomes.

Normally available ONLY to Artisan students, we’re offering this handy guide to you for a limited time!

More About #TransitioningToScrum

What Causes Conflict on a Team?

Change usually creates conflict, but a good ScrumMaster knows what types of conflict to expect and is prepared to handle it with correct conflict responses.

It’s All About Value

One small change can make a BIG difference to your Product Owner success. Before worrying about putting value on backlog items, here's some simple tips.

What Does it Mean to BE Agile?

With the Agility mindset, it's critical to understand the concept of "being" Agile. Some people want "to do Agile", but you don't DO Agile, you must BE Agile.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

As you found this post useful...

Follow us on social media!