Great video as usual, Mike. I've found using a Definition of Ready helped solve several problems we faced. But as you mention, it solved those problems at the cost of the gains that greater agility would bring. As a Scrum Master, I've been working to address the root causes of the issues that our Definition of Ready has helped to solve (or rather, to mitigate) so we can eliminate aspects of our Definition of Ready over time. It's a journey! But a worthwhile one, for sure.

@MountainGoatSoftware

8 ай бұрын

I love this, Dave. Using a Definition of Ready for the short term and then working to remove it is great.

I'm a fan of DoR, I've seen too many teams bringing in poor quality stories into a sprint, no acceptance criteria, items that are too large. Building quality into the process isn't a bad thing either, and slowing the team down to refine a story properly before the sprint does help. I do take your point though, and as always Mike, you challenge in a postive way. I still believe a DoR is a good thing, but that it just needs to be good enough and safe enough to be included in the Sprint, rather than a set of hard blocking rules.

@MountainGoatSoftware

8 ай бұрын

There are times where a DoR is useful, but at the end of the day we want to make sure that we aren't standing in the way of our team. Like you said, a DoR just needs to be good enough for your team to bring in quality work but not so restrictive that it blocks them from brining in any work.

@EntropyReduction-Agility

8 ай бұрын

@@MountainGoatSoftware DOR is usually established BY THE TEAM, not imposed ON the team. Therefore, the DOR is often a remedy for behaviors which have been getting in the way of the team. I like your focus on "overlapping work", which is really concurrent work and is necessary to guide the team to swarming stories. I have a series of videos on this concept (some are not yet public). So the sizing guideline as part of DOR can actually help ensure this takes place. I've helped many teams come to the realization that if they recognize they have a big story (5 and above, let's say), then they should discuss: "Should we slice, should we swarm, or both?" In this sense, the DOR guideline is promoting teamwork and a commitment to iterative delivery of a valuable PSI.

@MountainGoatSoftware

8 ай бұрын

Yes, the Definition should probably *always* be defined by the team. And yes it can remedy problems. It is great for that. But it does undeniably come at the cost of reducing overlapped work (concurrent engineering) and increases time to value. Those are negatives. Whether they're bad enough to decide not to use a DoR depends on the context. Many early-stage agile teams benefit from a DoR for awhile. I will check out your videos. I saw you have a few on your channel already.

Hi Mike, First of all, I have taken your online course on writting better user stories which I think it is amazingly well done. Highly recommendable. Regarding to this in my experience, I would agree that for example a mock up does not need to be completly done. But the team at the same time has to have information good enough on the acceptance criteria to be able to size and committ to finish the user story on the sprint. So there is blury line here on up to which point the team would feel comfortable on adding something to a sprint if we can not know the complexity of the case. It can be like signing a blank bank check to the business. Could potentially encourage the PO or the business not to create clear business requirements, if can be something added to the sprint anyway . The behaviour can end up, in thinking: Let's plan the user story as it is in the sprint, and add more requirements along the way on the same user story during the sprint? And I wonder, what will happen with the rest of the user stories have to be completed in the sprint as well if the story gets bigget than expected? In the scrum guide in the begining says under the title Scrum theory: Scrum employs an iterative, incremental approach to optimize "predictability" and to control risk. So I would go for to adding to the sprint a user story which has one or two of the acceptance criteria that is not that well defined but which the team knows that would not affect the size or complexity of the case. For example: we still have to decide if a button should be green or red, or placement in an interphase. Deciding this in the sprint will not affect the size of the case or complexity. But if in the mockup we are not sure about the rules or business logic that button will have, how in the mock up it will behave, I would not be so sure to add it to the sprint, a definition of ready can be useful,, since it can turn into a pandoras box in terms of size and complexity. It would need more refinement before adding to the sprint. I see a blury line between the agileness and waterfallness in this aspect. I brings me about the concurring engineering which were mentioned in other videos, so there should be some overlap of work, which I agree, in this scenario I would think if certain overlap on design and programming, but the question is, how much degree of overlap can be done? where is the line in which can maintain certain predictability on the delivery of the sprint? What are your thoughts about this? Thanks in advance!

@MountainGoatSoftware

7 ай бұрын

The big idea is to not let a definition of ready stand in your way of starting. Get as much information as you need to start then...start! As you iterate over the story, requirements will emerge, we'll learn more about what stakeholders actually want, and be able to adjust our course over time. If you don't have enough requirements to start a story, that's fine. Break the story down into smaller pieces until you have a part of that story that you can start on. Let's say that I'm creating a login page for a new website that I'm working on. Before I start, I don't know if I need to include social media as a method of logging in. I shouldn't wait until I know if I need to include that to get started. I'm going to start with what I know, then, when my stakeholders decide if I need to add in a way to login via socials, I can add it in. In your example; if your stakeholders don't know what the button should do but they know that they want a button, you can break that story down so that you add the button, put it in the place that makes the most sense, and incorporate it into your design with the information that you have. Your designer would figure out the placement and look of the button, your database person could create the database for whatever data the button will ultimately push (you'd have to take a bit of a guess at the datatype but it should be an educated guess), etc. Several members can work on that button without knowing entirely what it will do. Then in the next sprint you can add any functionality that your stakeholders come up with. Normally we shouldn't stop everything that we're doing to make a button that doesn't do anything. But if it's the only item, or the highest priority item, we should start with what we know. We'll learn more, requirements will emerge, and we can iterate over our button to ultimately do what it's supposed to do. We don't need to know everything to start. We just need to know enough to start.

Nice video and this time a bit trickier than usual, I had to see it twice ;) The key principles here: there is no strict rules. Context and conversations matter. Learning continuously. For example, this scenario happens often where some BAs are working hard to write the US for the dev team to start. Question to ask: Are the BAs part of the team? Answer option 1: yes ! Then we have here a normal overlap work. We don't pushed back the US with a DoR. Answer option 2: no !? Then we might have a conversation... I am giving you this example because the dependencies are often in fact barriers for collaboration.

@MountainGoatSoftware

8 ай бұрын

Good points and BAs are definitely part of the team. If not, that needs to be addressed.

@bgn9000fr

8 ай бұрын

@@MountainGoatSoftware thank you! This example of BA is quite obvious. Same question for UX, architect, security officer, compliance,... This is more difficult to say yes they are part of the team. However maybe they should at least for a period of time (enabling team in Team Topologies or Travellers in LeSS).

Good advice and an even more awesome doggie in the background picture!!

@MountainGoatSoftware

8 ай бұрын

That’s Mojito, my Havanese. :)

Yes. I have used DoR in many teams / org in the past and currently as well. It is very useful to bring discipline in the way User Stories are brought into the Sprints. DoR typically contains the basic minimal criteria the User Stories need to satisfy: for example, * describe the story in a typical format, * Acceptance criteria to be available, * functional dependencies to be identitied earlier, * INVEST model, * functional queries are resolved, * Story pointing done or ready to be done --- having these helped a number of teams to have more discipline in following Scrum. I think, DoR is dangerous only if it is not implemented correctly

@MountainGoatSoftware

Ай бұрын

I'm glad you've found an approach that works for you! That's great.

DOR should been seen as a guideline, and it definitely helps novice Agile teams. As the teams adapts to being and doing Agile, the quality aspect (DOD) gains more significance, their focus should shift to the value they are delivering in each increment than the readiness of work before including in the sprint.

@MountainGoatSoftware

8 ай бұрын

Yes, a definition of ready that is guidelines is good and can be helpful for novice teams until they learn to better collaborate and overlap work.

The reason we have a definition of ready, that contained acceptance criteria, was that we’d have bloat, and some feature never getting delivered, because a particularly influential engineer engineer would keep adding this or that technical aspect preventing its release. How do you deal with that issue?

@MountainGoatSoftware

8 ай бұрын

I would address two things: 1. why is that engineer so influential that he can "bloat" a feature for everyone 2. work with that engineer to demonstrate that some acceptance criteria (and other details) can be worked out in the sprint and that attempting to think of everything up front causes needless delays.

Oh Mike. I listened several times and just can't agree. Partially, but not entirely. This video is replete with internal contradictions. First, you want to convince people to NOT use a DOR, while conceding that a DOR can be helpful for some teams. Then why not focus on guidelines for when a DOR is helpful, and in what ways it might be counter-productive? You've basically said "Don't do it, it's a bad idea...unless..." More accurately: "It can sometimes have a downside." OK, so how do we avoid THAT? Now, look at your examples. "ALL A.C. have been defined". I've never heard anyone state that ALL the possible AC have been defined...but we have had to state that they are clear and understood by the team, and that the story meets INVEST...which will immediately point back to your cross-team dependency scenario. "The story has been sized and is

@MountainGoatSoftware

8 ай бұрын

Thank you for sharing your thoughts.

@durgasankarmandal9451

4 ай бұрын

Not sure if DoR and DoD comparison is fair. Especially for complex work. For complex work such as writing a thesis paper, I don't need every data with me to even begin, the varieties of data I would need may emerge and be collected later. But I need to have a pretty good understanding to be fit for consumption what every thesis paper should look like

@EntropyReduction-Agility

4 ай бұрын

@@durgasankarmandal9451 writing a thesis paper is probably NOT "complex work". That would fall under "complicated", at worst. Why? Because in the Cynefin model you'll see that Complicated problems fit into a category where the PROBLEM is well understood and does not change, there are existing Best-Practices and there are Experts who could be consulted. COMPLEX problems involve domains where the the PROBLEM itself is not well defined and needs to be explored, there may not be an existing "Best Practice", so the team needs to explore the problem and possible solutions.

Definition of Ready just seems like Waterfall to me

@MountainGoatSoftware

8 ай бұрын

In a lot of ways, it can be very similar

@EntropyReduction-Agility

8 ай бұрын

That just sounds like a facile way of disregarding a concept without actually performing deep thinking or experimentation. If a DOR is "waterfall": then the DOD is also "waterfall". Prove me wrong.

@MountainGoatSoftware

8 ай бұрын

Waterfall is defined as a series of sequential steps each of which can be started only after the prior step is complete. When a Definition of Ready says "this type of work must be done before an item can enter a sprint" that is exactly the same type of gate inherent in waterfall. A DoR defines the entry criteria for work, going back to when processes where described with ETVX criteria. The Definition of Done defines Exit criteria (the X in ETVX). Since the work is done after meeting the DoD, it's not waterfall since there's no subsequent step. (And if you say deployment may be the next step, consider a CI/CD environment, which would be more agile. But an organization may not choose to go that far as it may not be necessary. And choosing to batch work (for deployment in this example) in different than defining a process that requires it).

@durgasankarmandal9451

4 ай бұрын

@@MountainGoatSoftware Very well explained. Thank you.