Working Product and the DOD

This is one in a series on Scrum Intro. The preceding post is here.

Now we come to the Working Product. The big phrase is “potentially shippable product increment.”

What it means is first this: At the end of a Sprint, we expect every story that the team committed to in the Sprint Planning Meeting is “working” by the end of the Sprint. Working means built and tested, fully working (at the story level).

Working does not mean that we have built a full Minimum Viable Product yet. For the moment we are assuming that scenario where it takes multiple sprints to build an MVP.

We define working product mainly through the Definition of Done. We score points in the game (we earn Story Points for this Sprint’s Velocity) by getting all the items on the DOD done for a specific story. It’s all or none — either the story is fully done and we get all the points, or the story is partly done (or maybe un-started) and we get zero points.

The DOD must include two key things: The product is well built, and well tested.

The stronger the DOD, the better. There is strong bias toward the “quality is free” idea. That is, the sooner you build in quality, whatever that costs you, it is much cheaper (in every way) than building in quality later.

Why?

Why do we want working product at all? I mean, people will say that it is slowing down. They will say it is lots of trouble, and it is trouble. People will say “it is more work for me” — it certainly it will at least appear to be more work for them (although if done correctly, not more work for the team).

One answer (this is my saying): The bad news doesn’t get better with age. That is, identifying and fixing the bad news now is much cheaper than fixing it later.

Another answer is: We get better feedback from working product than from the documentation. Getting better feedback is very important. It is so easy to misunderstand what the customers (end-users) want. This bad news does not get better with age. If we spend less time building what they don’t want and more time building what they do want, we usually get done quicker. (OK, a bit of sarcasm, but getting done quicker is very important in several ways.)

Another answer. We have a better gauge how completed (what percentage complete) we are. In waterfall, the schedule would tell us we are 90 percent complete, and then awkwardly ask ourselves how much longer to complete the last 10 percent. (It was always a bad joke.)

Now, we identify the story point for all the work in a release. (Example: 120 story points in total.) And ask how many Story Points are completed (e.g., 60 SP). Then we would know how much of the work we have done (e.g., 50 percent) and how much longer it will take to deliver (roughly another three Sprints). This is much more accurate.

And (so much better, with more confidence) much more useful. For example, managers are less likely to cancel a release that is truly 50 percent done with many great features already built. Features that they can see, taste and feel — fewer stupid decisions.

What’s included in the DOD?

Here’s an example we typically use for software stories. Conceptually the basics are the same for about any product.

I always mention “better requirements” because that is so important. Really better requirements are part of the ready-ready criteria (some people are calling this the Definition of Ready or DOR), but it is important to mention now. This is key input to getting a story done.

It is amazing how much more work they can get done if they know what they are doing, and how much less work they get done if they have no flippin’ clue what they are doing. And by this, I mean if the requirements are clear. (The saying also applies to their skill sets, but normally this is much less of a problem.)

Example of starting DOD:

[good Req (better than ever before)]

• Analysis & Design (short)
• Coding
• Code Review, fix problems
• Testing
  • Unit Testing, automated, fix all bugs
  • Functional Testing, automated (80 percent), fix all bugs
  • INT/REG Testing, automated, fix all bugs
  • Any other testing…
• Documentation
• PO Review, fix any problems

The DOD is used to decide whether your team scored the 2 SP on Story 38 or not. It’s part of the “rules of the game” for the referee. There are no partial scores. It’s either done-done or not done.

A few comments:

We want clean code, good code, well-written code, code that anyone could understand and modify.

Again: If you are building a product that is not software, you must take the clean code concept as a metaphor, and define how that will work for your product.

We fix all the bugs. OK, we do allow people to come to the PO and make a case that “this bug does not have to be fixed ever.” That’s the only argument — that we will never have to fix this bug or defect. Never, ever. (Remember: The bad news does not get better with age, and you have to slow down to go fast.) Very rarely the PO may agree. The bug is moved to an “issues” list.  Usually at least half of these bugs (so moved) must be fixed later at much more cost. You shot yourself in the foot.

Functional Testing is called lots of things. It is the testing done by your good QA or testing people.

We recommend that some documents are updated every time we do a story.  There is a longer discussion about which ones those are and exactly what that means.  No documentation is unacceptable.  And no documents being updated (however much or little) each time we do a normal story is… something I just cannot imagine happening with any professional team.

PO Review — This is important. We want a mini-demo each time a story is done, or almost done. The PO can say “now that I see it, it’s not quite what the customer will want” and ask for some changes. The PO cannot add all or part of another story at this point.

The doers will say, “But, we built it according to the spec,” (and usually they will be correct about that) and then ask, “Why wasn’t this new information in the spec?” (the enabling spec).

There is not a happy answer to the question. The doers should have asked a question earlier and the PO should have answered the question earlier (whether asked or not). Nonetheless, we have to accept that the PO (and others) will still learn things later than they should.

This does NOT allow the PO to be irresponsible and learn just anything later, but, we must accept that once he or she sees the built story, the PO may discover that it must be changed. And, as long as the change is within the scope of that one ticket (that story), then the change must be made before that story is done.

Have we really made progress if the customer will not be happy? No. So, it ain’t over ‘till the customer is happy (or, until the PO thinks the customer will be happy).

Is the PO always right? No, but we have to have some independent person decide quickly. The PO (or anyone he/she designates) is that person.

There should be some thoughtful discussion: “Why didn’t we discover this problem earlier?” It is not a blame game, but rather a search for the root cause and an attempt to become better as a team.

We want about one mini-demo of this sort about each day. So, for example, all the testing is not done at the end of the sprint. Most of the eight or more stories should be done before the last two days in the two-week Sprint.

The next post in this series is TBD.

The whole draft book can be found here.

« « “Do or do not. There is no try.” || The Agile Challenge » »