Done, Done-Done, Done Done-Done?

The "Definition of Done" is a fundamental artifact in Scrum.
It allows the team to decide when they can safely consider their work "Done".

However, many times, team fall into the trap of "Done-Done".
The root cause is usually external dependencies, such as being unable to test software ("Story Done" vs. "Test Done") or a separate Operations team ("Go-Live Done").

At scale, matters quickly worsen: Sprint-Done doesn't mean that there is a Working Release, much less that it has been deployed to Production.

As a first step, the solution is usually to come up with separate definitions of Done.
When describing these, please note that I mean: "First Step" of improvement, not something to be proud of. Having half a dozen of Definitions of Done is a smell, an indicator that something is very, very wrong!

Here are some definitions I have already encountered in the past:

Story Done

The basic activities required to say "We're done with development". Basically, this typically contains fulfilling all Acceptance Criteria, Code Review, Pull Request approved. Ideally, the Acceptance Tests are fully automated as well, although that one is already a compromise in many large organisations.

Sprint Done

The basic activities required to say "We're done with development". Basically, this includes that the Product Owner has accepted all delivered Stories and having merged all Stories into a Green Master.

Test Done

After developers have built "Working Software", it must be deployed and running on an integrated test environment where you can test the interaction with other components and services as well as with real people.
Some parts of the tests that may need to be done include Integration Testing, Performance Testing, Exploratory Testing etc. Just refer to the Test Quadrants to get some ideas of what may be needed.

Deployment Done

After tests are passed, the software must be Up and Running on a Live System. Alternatively, if you are shipping Vendor Software, it means you have a Shippable Product that has gone out to the customer. 

Release Done

 A Release is "Done" when no more activities related to the release are oustanding. Beyond deploying Working Software, it may include automated monitoring and reporting, looking at first figures on the Live Server etc.

The illusion of "Done"

At worst, you end up with a state of Done-Done-Done-Done-Done-"Not Done-Back To Step 1", where faulty stories need to be fixed weeks after they were marked "Done".
As a consequence, old work starts to flow back into current sprints, reducing predictability, velocity and morale.

Oftentimes, companies take this venue because either:

• There is too much pressure to get something "Done" 

If this is the case, management must be educated that they are sacrificing a high amount of sustainability for an insignificant increase of speed.
Listing the "hidden factory" work that must be done by the team outside of "Story Done" and figuring that into the total cost of delivery may help.

• They don't know how to do it differently

 From a strategic level, this is easy to fix. Operatively, it requires a lot of organizational change.

 

Minimize "Definitions of Done"

Team Definition of Done

A "Story" should not be "Done", followed up with additional work to get the "Sprint Done". The first step is to eliminate this gap.
"Story Done" should be attained when there is no more work that the team can do in the sense that from the team's perspective, there is Working Software by the time Story is set to "Done". A story is never "done" unless it is already integrated into the Master and ready to deploy to Production.
Provide a single Definition of Done for the team that includes everything the team can do. Accept no compromise, no intermediary steps.
Other teams can do this, so your team can do it, too!

Organizational Definition of Done

Never take the route of splitting into stuff like "Testing Done", "Release Done", "Deployment Done".
When setting out, catalog all "undone work" which the team does not do that happen before actually bringing the software into production into a single "Organizational DoD" (ODoD).
After creating a catalog, start out by eliminating the obvious waste.
Then comes the tricky part.
Every item on the ODoD should be considered an impediment for story delivery: Anything "urgent" is always blocked by the ODoD.
Depending on your organization, it may take years to move all items from the ODoD towards the team. This should not discourage you from undertaking the journey: Every reduction to the ODoD increases the organization's flexibility and risk of failure in case of emergency.

The Vision of "Done"

There is a single Definition of Done for each team.
The teams act upon this definition and not anything else.

The team can complete all activities necessary to reach Done.
No other party must become active for any item to become Done.

"Done" means "Done".
There is no work left to do when the team moves the card to "Done".

We know it's over.
The risk of failure is already eliminated, so there will be no residual risk of having to undo.

Weeding out the backlog

When companies transition to Scrum, or any other Agile methodology, they usually start with the problem of arranging all the identified "undone work". Where do we start?

In the worst case, huge amounts of "overdue" items are all considered "Priority 1". In this situation, the Product Owner must clearly indicate where the team should start.

Other organizations seem to suffer from a kind of collection addiction, keeping a backlog of hundreds of items that won't ever get done.

Here are some tips for maintaining a nice, tidy, workable backlog.

Intially setting up a backlog

Before even bothering to produce detailed user stories or doing task breakdown, the Product Owner should simply draft out the basic areas of the Product. 

Post-It notes with maybe one or two words will do the trick. Then, draft the matrix below on a board and place the sticky notes:

The backlog item placement matrix

Put your backlog items on this matrix!

Impact

When weeding out based on impact, you must identify your customers and stakeholders. For each item you identified, you must ask "Who will suffer if this is not implemented?" 

If the impact of not implementing the item is low or not even measurable, the item is certainly not important.

Urgency

Next, you weed out based on urgency. A good initial question to ask when chaffing out for initial urgency is: "If we do not deliver within 1 month, will there be significant damage to our business case?" - if the answer is "no", the item has low urgency.

Unclear cases

If you're unsure, feel free to put the item on the dividing line between low/high.

When that region clutters, you can benchmark by using the top item on the dividing line. Ask yourself for each item: "Does this have higher impact / urgency?" to make a decision quickly.

Scrap

Ideally, you will end up with a good number of items in the "Scrap" section. Congratulations, they are off the table! You do not need to waste any further minute with these topics.

Defer

For anything in the section "Defer": put those items on the bottom of your backlog and leave them there. Do not waste time now grooming them, because you will not work with them in the near future.

Why?

For anything in the section "Why?":

If you would invest a lot of effort for little impact, move the item to the "Scrap" section.

When you're just starting a new product, it's probably a bad idea to have anything from this in your backlog, because you want to get your product going - NOW!

When you're working on an existing product, you may want to look for "quick wins" in this section. Anything that will give you a credibility boost at low cost should be considered.

As long as the item still has a positive Return on Investment, you should do it, but only if you can squeeze it into the schedule.

Only groom items which will bring your product ahead with minimal effort. 

Move the others into the backlog until further notice.

Do Now

Should you have significantly more than five items here or dispute over priority, you need to weed out further.

The items remaining in this section are your high level backlog ("Epic items").

These items need to be made workable, such as by using INVEST. Break them down to feature level and start with the Story Breakdown.

Ordered weeding

If you feel uncertain about being too lax with weeding and up with a cluttered "Do Now" section", you should use "Magic Numbering" on the cards twice.

During the first round, simply arrange the cards by impact. After finishing, arrange them into buckets from 1 to 5 with ascending impact and note the impact on the cards. Unless you have less than 6 items, each number should have at least 1 item.

During the second round, arrange the cards by urgency from "low" to "high" in ascending order from left to right.

Then, use the noted numbers of impact to move the cards up (high impact) or down (low impact). Make sure their horizontal position remains unchanged. when arranging them on the vertical axis.

Afterwards, draw the lines - not in the middle, but between the "3" and "4" rows and columns, so purposefully create a bias towards "High".

Wrapping it up

You may flinch when you see that "lots of valuable stuff has gone off the list", but if you did the arrangement correctly,  only "even more valuable stuff will get done".

Your initial backlog should be very small and tidy at this point, easily workable for further breakdown.

Likewise, you can immediately and effectively quench discussion about any other topic with the simple argument "It won't get done now, anyway".

Recursion

You can apply the same process with the story / feature breakdown of each item. When moving into the first sprint of the team, it's actually a good idea to not overload the team with information. Weed the Ready ("groomed, broken down, workable") backlog to no more than five workable items for the first sprint.

Sprint planning

After the sprint, you will learn about the team's capacity. The amount of items you need to have Ready for the next Sprint should be roughly equal to twice the team's velocity. 

Once an Epic ("high level") item is fully groomed and there are not enough Ready items in the backlog, you take the next Epic and break it down. Start with the "Do Now" items and pull from "Defer" or the "Quick Wins", depending on what currently makes more sense.

Iterating

Impact and Urgency are subject to change. For instance, in May, the annual fiscal report is not urgent - in December, that's an entirely different story! Or, you have a customer threatening with a lawsuit - that may make an otherwise insignificant topic very urgent.

Whenever an item is added to / removed from the Epic Backlog, priorities may change. Between each sprint, you should bother taking a couple of minutes to do an iteration of weeding to make sure you are properly set up for the next sprint. 

Consequently, stories that were groomed on a detailed level may move to the "Scrap" section. That is okay. If the current product priorities indicate that this makes sense - so be it!

Don't bother tracking backlog that nobody will work on in the near future.

A good indicator of when you should weed:

You have items in the backlog that were not touched for more than 3 Sprints, and nobody has bothered asking about them.

Use frequent weeding to keep a significant, concise backlog.