Done vs. done done

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.

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.

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.

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.

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.

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.

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.

@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?

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.

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.

+ 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".

My 2 cents worth.  The Capability Maturity Model of Carnegie Mellon University offers a take on the above.  I.e. if you operate without processes you are essentially operating heroically at CM L1.  CM L2 are project processes for either Traditional or Agile (Scrum).  Essential CM L2 processes are PP (Project Planning) and PMC (Project Monitoring and Control) for for a particular (Requirement) the CM L2 process REQM is used.  This is "minding the gap" between a plan (2 week sprint is also a plan) and then checking that delivery has happened at other end.  The CM L3 processes are "pretty much" software engineering processes.  Of interest are CM L2 VER and VAL processes.  I.e. Verification (I as business user agree this is what I want) and Validation (I as business user agree that you gave me what I wanted - think UAT).  The above said if working software is not being produced this must increase risk or CM L3 RSKM process as money is being spent sprint by sprint for a bunch of expensive resources who may not delivering and could be a UNDONE SCRUM TEAM.  If management have agreed to go agile (because they cannot find the time or have the maturity or capability to build strategic direction into their software engineering) then the only way to ensure delivery in Scrum is at the Demonstrate and Validate process of say (Scrum process #16).  The Product Owner MUST approve the demo and offer comments that demo has delivered else operating heroically.  Now, to get to where I believe the above discussion needs to be at:  If you look at ITIL (The IT infrastructure Library moving from version 3 to 4 there are 5 lifecycle phases.  Service Strategy (a project method = software is moved from 1 baseline to new improved baseline).  Software Design (dev), SW Transition - to produce DML for testing and UAT. SW Operations (in live) and CSI Continual Service Improvement (The Scrum Backlog).  Gene Kim says ITIL is not in opposition with DevOps. 

[1] One option to increase the sprint length to 4 weeks to perform all the necessary tasks/activities and release a working piece of work. 

[2] Kanban

Thanks.

It is not done until it is done done.  This concept of the difference between done (dev done) and ready for release is understood by us in agile as done done.  I.e. If it is done done this means that it is dev done and ready for release if working through the testing processes applied in ITIL Service Design and Service Transition and approved by Business or Client in UAT (verified [VER] requirement [REQM] is validated [VAL]) then feature (user story) is ready to deploy to Service Operations).  I suggest that screwing down the delay between dev done and done done is the essential challenge we face in agile. Sadly, if the concept of agile is that you do stuff faster then, without process understanding and focus, faster could mean less quality (and more heroics) and an inability to correctly make the user stories done done.  I see a small shift in business of late (2020) where fragile and aino are now being incorrectly attributed to "scrum metho" not working.  I.e. let us choose some other thingy to get stuff done done.  The mistake is that choosing ScrumBan means surely that processes are being missed out (ITIL, CM and project processes) = CM L1 heroic solution.  Another mistake is in choosing Kanban as the way to get faster to done done.  But Kanban is all about feature focus and how many features are coming online / how fast etc., when looking at all the work the team are doing.  Kanban is also not a project method.  i.e. no sprint / burndown so thinking it is is delusional.  Remember ITIL expects a project in Service Strategy.  And if you are making changes to software baselines without a plan (evan a short scrum iteration) then you will surely get bogged down in the "tar pit."