Some days ago we had the retrospective meeting and as a kick off for the discussion we wanted to describe the sprint by using one word. Most of my colleagues described their current sprint with “Successful” so we agreed to dig deeper in the topic and understand what happened, what were the factors that contributed to this success, what activities should we as a team continue doing in the future.
To cut it short: team appreciated the flow of user story readiness resulted from the frequent backlog refinement sessions we had prior the sprint start. This allowed us to bring to Done all the forecast stories and have a good feeling also for the upcoming sprints.
We’ve continued afterwards the discussion about the characteristics of a good User Story, reviewed the INVEST checklist and brainstormed about the criteria used when assessing a user story to be “ready” for development.
Someone from the team exclaimed: “This could be our definition of ready! We can ask our Product Owner to consider this criteria when writing the user stories! This will make our life so much easier!!”
After a couple of seconds of silence, another voice could be heard: “But wait, we are writing the User Stories together with our PO. This practice should be continued also in the future!”
What is the Definition of Ready?
The definition of ready is a working agreement for the team that states what a user story must have in order to be planned in the next sprints. This tool can be very helpful especially for teams that find themselves at the beginning of their agile journey, for example to strike the balance between too much and too little detail when writing user stories.
I’ve seen a lot of teams sprinting without having in advance the proper dialogue between what is possible and what is desirable. Hence the typical tension between what is desirable for the customers, what is viable for the business and what is feasible with the current technology within the target timeframe is far to be resolved. One consequence of this practice is for Scrum teams to start their sprint with user stories that contain too little detail, which makes them impossible to plan properly. And this can be very frustrating as nobody wants to start working on User Stories that are too fuzzy to be successfully finished inside the sprint. This is one of the situations where establishing a Definition of Ready can be extremely helpful.
A double-edged sword
Sometimes though, with the aim to build on top of the established Definition of Ready, teams start to become very strict about what “ready for development” means. During their retrospective meetings, they will try to continuously improve their process and whenever communication problems between Product Owner and development team arise for example, the natural tendency is to extend the Definition of Ready with a new policy. After several “improvement” sessions, someone will realize that instead of the silver bullet that solved several troublesome sprints, they may have implemented a wall, an over-regulated process, that impedes collaboration between Product Owner and Development team
And most of us have witnessed the never ending discussions on how the Product Owner should specify their requirements correct, complete and consistent, pre-approved if possible by another Product Owner (higher on a hierarchically scale) and also software architect — “just” to make sure that the missing details are covered. And the story continues with the development of templates, processes, approval meetings and so on…
- What if the Scrum team uses the DoR during the backlog refinement session to assess the readiness of the backlog items and not as a sequential, phase-gate checklist?
- What if we change the wording by generalizing and creating guidelines instead of making strict, specific contracts (between development team and PO)?
In case we really need a Definition of Ready, we have to remember to not forget about the agile principles. As opposite to the Definition of Done which should grow along with the capabilities of the development team, the Definition of Ready should shrink, as the team will become more and more capable to handle incomplete information.
Teams must become more comfortable with uncertainty. When one thing cannot start until another thing is done, the team is no longer overlapping their work. An agile team should always be doing a little analysis, a little design, a little coding, and a little testing. Putting gates in the development process prevents that from happening and the establishment of a definition of ready can lead directly to such an approach.
What are your experiences with defining what ready for development means?