DoR vs DoD

Definition of Ready vs Definition of Done

I have tried my best to apply Agile principles and scrum at a lot of projects. Things have worked out well, where we have built & delivered an MVP and have shipped it to production. There has been an "Acceptance Criteria" and a "Definition of Done" in all the user stories. However, the user acceptance has been poor in some of the cases. It returns with a lot of bugs to fix or a lot of change in requirements. Ideally, the engineering department is the one wasting a lot of time reinventing the same wheel.

I have always wondered what is the cause of this? Where should the process be fixed? Well, recently, I got to know about one of the factors. It is a three "lack" problem.

1. Product Owner
2. An Agile Coach
3. Definition of Ready -- The key according to me

Purpose of DoR

The purpose of DoR is to ensure that there is enough information in the product backlog for the development team to take up an activity. The key person to provide the person would be a product owner and the scrum master has to ensure that these activities are happening on a daily basis.

I am of the opinion that a single backlog grooming may not work out but this has to be a daily activity between the product and engineering team

In some of my experiences, the Definition of Done or the Acceptance Criteria was just a one liner or a Figma design. With just a single line, what could an engineering team do? It calls for a more reactive approach where the onus of figuring out the requirement, mapping out the business logic, figuring out an appropriate data model, etc. falls on to the engineering team. This results into a lot of design confusions, back and forth discussions between the engineering and product team, and literally a lot of time wasted resulting in a low velocity. These are all unwanted sediments at the engineering layer.

Engineering is a downstream system where all these product requirements etc. has to be filtered out at the top layer by the product owners. There would be minimum contribution from engineering but majority of this would be handled by the product owners. They are the key to limit all the unnecessary work being passed on to the engineering team. However, this might become and anti pattern, where the engineering team demands all sorts of information from the product team. There has to be a fine balance to start work with minimum ambiguity. All the cases that I have witnessed is, time pressure with lots of ambiguity and the buck passes to the Engineering team to start the development

I have stumbled at various sprint planning/grooming sessions with the following situations.

• The priority stories that needs to be taken up for the sprint is not groomed enough.
• A need or a feel to discuss all the 100 stories in the backlog grooming or sprint planning meeting. After the 10th story, we would have run out of meeting time or exhausted resulting in an improper grooming or planning session. Resulting in adding stories in between sprint, changing scope, etc.
• The user story is empty. Its blank and when we do our poker planning (A side note, https://planningpokeronline.com/ has been great while doing the poker planning online), we have nothing to estimate

How many of you have faced the above situations?

All the above can be avoided having a "Definition of Ready". While Definition of Done is the exit criteria for dev complete, Definition of Ready is the entry criteria to start development.

Some of the disadvantages are, it creates dependencies and slows down the development, hampers parallel processing. However, identifying boundaries, mapping dependencies and accepting nominal delays are much better than screwing up the whole project. A detail oriented Agile Coach, Scrum master should be able to identify the gaps, overcome the delays and stitch an optimal process around the issues faced.

The other best practices that have helped me in Scrum/Agile are:

1. In case if you have an option to split the team based on horizontal or vertical, split it. A max of 7 member team helps to define clear boundaries, tasks etc. However, handshaking between teams have to be handled properly.
2. The above helps to run parallel sprints, track velocity per team, and helps to identify bottlenecks within team, process, etc.
3. Define predefined templates of tasks & assign average story points for data and app team based on past experience. This eliminates a lot of sprint planning time. However, address any ambiguities and uncertainties based on specifics
4. Map story points to days or hours. I have read a lot of posts against it, but has worked for me at few occasions.
5. Don't get into a lot of granularity. Granular activities, makes ur backlog clumsy and difficult to plan. If required, move them as sub tasks.
6. Create a "never to be started" sprint which will be a subset from Backlog and use it for sprint planning. Backlog could be a long tail. Move the high priority, groomed with DoR into this sprint and use it for sprint planning
7. Create separate states for External dependencies and call it out separately

I am neither a Scrum master nor an Agile Coach and these are my personal experiences. I keep a keen eye on planning, process, running things in parallel and ensure that my team doesn't burn the midnight oil unnecessarily.

As an end note " The Definition of Ready" should give the confidence to an engineer to build a feature without a major hiccup and finish it in style!!!!

References:

1. https://instituteengmgt.com/wp-content/uploads/DoRDoD.pdf