Done vs. done done

Last post 03:05 am December 22, 2018
by Uma-Venkata Ratna-Kumar Lekkala
11 replies
Author
Messages
07:03 am June 22, 2014

Hi all,

Within my current company I'm facing with the following problem.

Our development is using scrum to deliver small stories. This is going well and we've build up a steady pace within our 2 week sprint.

Although the development team is doing a good job in delivering stories every 2 weeks, the story is not 'done done'. After the stories are 'done', other external process (which are depending on the stories, like some hardware modification etc.) gets started.
So, the team is able to produce stories within 2 weeks, but for it to be 'done done' we're usually talking about several months.

What to do? (by the way including these external processes is not an option)

02:58 pm June 22, 2014

Incremental releases can be seen as part of a value chain, where value is added by different stakeholders at different points. One team's understanding of "done" may not match that of consumers further down the chain. That doesn't necessarily mean that there is a problem and that the team's DoD is inadequate. The increment might well be fit for purpose as far as a PO is concerned. He or she might simply plan to add further value to the product in order to sell it on, this perhaps being their business model.

The key consideration is that of technical debt. If you find that you have to perform rework as a result of the "external processes" you mention, then you do indeed have a problem, and the DoD is not fit for purpose.

01:41 am June 23, 2014

Hi Ian,

This is the case. Sometimes problems gets discovered during that phase which results in rework.

Now that external (hardware) process that comes after software development is a very complex process which is almost unplannable. Only when we're in that second phase, we find out what we're missing.

03:20 am June 23, 2014

OK. The first thing to do is to deduce (or estimate) the cost of this rework. If you have a hard figure of what this is costing the company, you are more likely to get executive sponsorship for a solution.

The figure should include the time cost of teams performing the rework, the cost of any additional resources consumed, and the cost of delay incurred by having to revise the product before it can reach the market. Other things to factor in might include a wider missed opportunity cost (while a team is tied up doing rework, other opportunities may pass the company by) and quality cost or cost to reputation (since not all of the technical debt may be discovered during rework). These are harder to estimate.

I recommend getting a figure like that first. Once you have it, you should effectively have a budget for working out a solution.

06:07 pm June 23, 2014

My team faces the same issue. Although for us, testing is the piece that doesn't quite fit within the two-week sprint so stories and tasks that are implemented in sprint 1, aren't testing by QA until sprint 2.

07:27 pm June 23, 2014

On similar lines what Ian expressed - I wanted to put my views. Please feel free to correct me

Quite often vendors or external parties don't adopt methodologies which organisations practice .

A working shippable product increment (definition of done) has to be determined within spring planning.
So a risk has to be logged with PO if by any means we think definition of done will have a external dependencies.

Also, Vendors or external parties should be made clear (with support from management) that sprint goal is important and they should show up instead of delaying the results.

I think the best way would be to include this support role into development team so that they will have accountability / ownership for the sprint goal.

If current sprint testing and QA is done in next sprint , it's not scrum but we can name it as ScrumBut. ScrumBut can never have desired results as Scrum.

03:57 am June 24, 2014

If I understand correctly, you are trying to scale Scrum. What you call "done done" should just be called "done". The definition of done for each team should include integration with all other teams. This means it might be impossible to have 2 week sprints, because it is not enough to deliver the stories. If hardware is included, it can even be very difficult to have 4 week sprints. If your company is fine with several months of development, and you do not need to be more agile, that's OK. You can consider the software of your team as the product which is delivered to the other teams who are stakeholders, and you can do isolated Scrum.
However if the market and competitors force you to be faster than that, you should think about how to get to 4 week sprints with an integrated increment at the end. There are approaches for this like rapid prototyping.

03:25 pm August 28, 2018

Since we all have different backgrounds and we all work on different industries, I will add my experience with mobile app development to this discussion, in the hopes it gives some guidance to my fellow Scrum Masters.

The way I explained this "UAT as part of the Sprint" situation to my client was: In SCRUM, the team members are Product Owner, Development Team and Scrum Master. So, in theory, there are no users as part of the SCRUM team. (It was funny to see all those surprise faces on their faces...).

But in reality, there is user influence on a SCRUM team, and it is the responsibility of the whole team to make sure that happens. We do not develop anything if we have no idea what the client wants or what they will accept. (If they really know what they want, which is another discussion altogether).

The Product Owner takes the initiative to understand what is needed, what is wanted and what is acceptable. She/he will understand the business needs and the specific “gaps” that the new product is to fill. The PO needs to gather as much info as possible so, when delivering the User Stories, both the Acceptance Criteria and the DoD are in complete alignment to the needs and wants of the client. That way, even the PO can make the call and accept an increment. (“Yep, that’s what they want!”)

The Dev Team provides the PO with the technical aspects of the needs and wants: is it possible? is it doable? it is logical? is it appropriate? Yes, the Dev team has the “know how” to provide feedback to the business needs and “temper” the wants of the business with the “alignment” to technology boundaries. Example: “I want to have an auto login feature but also I want my users to be permanently logged to parts of the app” The PO is conveying the wants and needs of the Users (and probably didn’t though about it), but the Dev team should feel empowered enough to say: “You know those two requests are conflicting, right?”

Once the User Stories are agreed, weighted, scheduled, assigned and started, Scrum tells us “We won’t stop until is done!”. We need to consume the timebox of the Sprint. We need to deliver an increment. And to do so, we have to test. But we test not against the User’s wants or needs. We test against the Acceptance Criteria and the DoD.

Once the increment is completed, dev & tested, we deliver that to the PO (“put it in the shelve”) for the client to use. It should be complete, complete….against the DoD and Acceptance Criteria.

The issue I see is: But what if the UAT finds issues? Or wants to change things? Or needs to change things? How do I avoid the “You didn’t give me what I wanted!” discussion?

The short and sweet answer: You DID deliver what they wanted. It was documented, discussed, groomed, edited, updated, formatted, distributed and all the things you can do to User Stories. There are two reasons why the “That is not what we wanted” line will come up:

  • Business Requirements changed during the Sprint: New sponsor, new marketing requirements….you name it. If something new comes up, it is the Scrum Master job to communicate appropriately…delivering the lifesaving line: “We will add that to the Backlog”.
  • Unclear requirements gathered from users: if the job was not done correctly and with an abundant of questions & learning scenarios, your PO will end up “assuming” requirements….and I really don’t like that. What the PO writes on the Acceptance Criteria and the DoD must be a clear and direct reflection of the wants and needs of the client. “Assuming” something is a recipe to get an “I don’t like it”.

Based on this, I’ve always been a proponent on my projects of having UAT outside the Sprint. User Acceptance Testing is testing that the user does to accept something as correct and ready to PROD. And by definition, this should be already included on the Acceptance Criteria and the DoD.

But I got a feeling that most of us wants the answer to the ultimate “UAT on a Sprint” question: What do I say if my increment is not liked or accepted by the client/user. Well, it should not happen, if we’ve done our work correctly. But if it does, you then have another item for your next Sprint. (I can see more weird faces again here).

Yes, once a Scrum team delivers an increment, it is a working element, capable of being implemented based on the available details provided on the User Story. Not accepted? Add the item to the backlog. (Rework – User Story #29 – Logoff…or whatever). For one thing, in this way you are not only tracking rework waste, but the client/sponsor understand that waste, and should encourage them to align their business processes to the SCRUM methodology. Businesses will not change their processes if they can’t understand the numbers. And showing them how much rework waste is incurred is a good motivator for change.

02:24 pm December 14, 2018

@Pedro Robles 

Your explanation is very interesting. 

I just wanted to have your feedback regarding what you describe below

"Once the increment is completed, dev & tested, we deliver that to the PO (“put it in the shelve”) for the client to use. It should be complete, complete….against the DoD and Acceptance Criteria."

What will happen if after the UAT it is proved that some of the DoD and Acceptance Criteria are not met (even if the scum team declared or thought that they were met).

Isn't this a case where the UAT could act as a verification mechanism to what was agreed as DoD and Acceptance Criteria? Would it make sense under this scope to include the UAT in the Sprint as a way to ensure that the DoD and Acceptance Criteria have been met?

A potential user for performing the UAT could be the PO considering hat he/she represents the users/clients (or whoever represents the other side). Does it make sense for you that what is declared as "done" from the development team has to somehow been checked and verified from somebody from the other side before it is actually delivered in production?

 

02:25 pm December 18, 2018

Pedro, from my perspective, you've got some things right, some quite the opposite. Just me opinion, and here are my arguments for your take:

I will add my experience with mobile app development to this discussion, in the hopes it gives some guidance to my fellow Scrum Masters.

I’ve always been a proponent on my projects of having UAT outside the Sprint. User Acceptance Testing is testing that the user does to accept something as correct and ready to PROD. And by definition, this should be already included on the Acceptance Criteria and the DoD.

But I got a feeling that most of us wants the answer to the ultimate “UAT on a Sprint” question: What do I say if my increment is not liked or accepted by the client/user. Well, it should not happen, if we’ve done our work correctly. But if it does, you then have another item for your next Sprint. (I can see more weird faces again here).

Yes, once a Scrum team delivers an increment, it is a working element, capable of being implemented based on the available details provided on the User Story. Not accepted? Add the item to the backlog. (Rework – User Story #29 – Logoff…or whatever). For one thing, in this way you are not only tracking rework waste, but the client/sponsor understand that waste, and should encourage them to align their business processes to the SCRUM methodology. Businesses will not change their processes if they can’t understand the numbers. And showing them how much rework waste is incurred is a good motivator for change.

 

Each development cycle (sprint), can be, as most in the industry know, considered a project in itself. It is limited in time and people resources and it aims to get from nowhere to somewhere using the existing resources, under a specific timeframe, in order to reduce risk/waste, and to get something valuable built or addressed. Unlike the traditional approach, where each phase follows the previous one and they don't otherwise "meet", for software it was proven that it is considerably better not to split into phases. 

You suggesting UAT has to be done outside of the sprint suggests the traditional approach is actually correct, and there has to be a split between development (and associated internal testing by QAs, if any) and UAT (UAT that, following your analysis, is always done by the client/user).

What prevents you from having the client/user, regularly cooperate with your team (predominantly with the PO), and either trust PO's acceptance throughout sprint (if PO is knowledgeable, or was trained, etc), or otherwise have a BA part of the team, to cooperate with the DT daily throughout the sprint?

Your assumption seems to be that the increment has to be accepted. I have a different view, as I believe each story has to be accepted, and then you really don't have to worry about the increment being accepted. And to get each story accepted, you need daily cooperation between the business (PO, BA) and the developers so that work/progress is inspected, adapted, planned (during DS), reviewed, and if there are variations/problems/confusions, act with celerity.

I may be wrong, but it also seems to me you're confusing the acceptance criteria and the definition of done. Acceptance criteria is/are limited to a particular story/set of stories (maybe similar ones, within same epic? - depends). The definition of done applies to the increment itself.

You should never reach a moment where the increment is not "liked or accepted" by the client/user. That's the pure definition of waste. Look above (daily cooperation between business and developers!) to understand better.

In terms of "align their business processes to the SCRUM methodology" I'd argue there is no process alignment needed. It's not about processes, it's primarily about people and communications. And note Scrum is a framework, not a methodology (as a SM, since you used the word "fellow", you should already know that).

"Businesses will not change their processes if they can’t understand the numbers" - numbers are actually quite easy to understand. Value, transparency, communications/interactions, is what they want to chase.

I'm afraid to say that, in my view, your guidance (as you call it) isn't in agreement with the Agile principles, nor is it in agreement with Scrum.

02:52 pm December 18, 2018

Babis, is my view, Pedro's approach is incorrect and you should research more to get a better understanding of the most suitable approaches.

Once the increment is completed, dev & tested, we deliver that to the PO (“put it in the shelve”) for the client to use. It should be complete, complete….against the DoD and Acceptance Criteria.

The increment in itself is never "completed, dev & tested". "The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints". You want the parts (stories - features, improvements, whetever you call it; bugs; etc) completed within a specific period of time (a sprint). Completed means coded, tested, and accepted by the business (that's the UAT!), so that, by the time the sprints ends (if you release once a sprint), you are ready to ship software to production (if the business-PO wants, and they usually want).

Don't confuse the DoD with the AC (see above).

 

What will happen if after the UAT it is proved that some of the DoD and Acceptance Criteria are not met (even if the scum team declared or thought that they were met).

The AC are specific to each item. Some AC can be similar (the very same) for two or more stories. But you'll never have AC at increment level, just like you won't have DoD at story level. Do some research online to understand better.

 

Isn't this a case where the UAT could act as a verification mechanism to what was agreed as DoD and Acceptance Criteria? Would it make sense under this scope to include the UAT in the Sprint as a way to ensure that the DoD and Acceptance Criteria have been met?

In Scrum, UAT should always be part of the sprint, otherwise you wouldn't be in a "potentially releasable" state at the end of the sprint. What you'l have is some sort of circus where the so called Scrum team would say they are done, but they need to await UAT results to be done done (!?) - and let's hope the business will "accept the increment" (!), then they need to prepare the actual release to be done done done for production (!?)

 

A potential user for performing the UAT could be the PO considering hat he/she represents the users/clients (or whoever represents the other side). Does it make sense for you that what is declared as "done" from the development team has to somehow been checked and verified from somebody from the other side before it is actually delivered in production?

Depelopment team cannot/should not "declare as done" anything. There should be constant (daily if possible) interaction between the developers and the business (PO, BA) in order to clarify confusions, ensure work is done against the acceptance criteria (for those who use it - or ensure Gherkin scenarios are accurate, etc), test work, and so on.

There should always be business acceptance, from an user perspective (and done within the sprint!), regardless of who does it (PO, BA, even SM if they are knowledgeable). I should note I've requested support, on many occasions, from people outside the Scrum team, in order to test work done for their benefit when the business rep were not available, or there was none); but again, all this was done within sprint, and in some instances, there was some pressure on them (as they ovbiously had their own jobs to do!), but we've got to adapt when needed.

03:05 am December 22, 2018

+ 1 Ludwig Harsch

What you call "done done" should just be called "done"

There is no such word as "Done done" in Scrum guide, though I understand what is implied. Ideally you want to reach the "done done" state as per the intended meaning here. So what is the point in tracking the done items, if that is not their eventual state and therefore why use the "done done" state instead of making sure you "Definition of Done" is STRINGENT to begin with?

Please work as a team to make your "Definition of Done" more stringent so you do not need such a thing as "done done".