The most famous list of software development. Part 1, Definition of Ready

The articles from this blog appear not only here, but in several other places such as Reddit, Mastodon, and others. There is even a Russian twin-brother of it, the one you can find on itakspisok.blog. Articles from it go to different places, e.g., to the dedicated Telegram-channel. Telegram is well-known for its active socialization of people who have channels there. I thought that there wouldn’t be anyone proposing something to me before at least 1000 subscribers, but I was wrong.

One day, Alexander, the creator of the IT-related channel, wrote to me and proposed to tell about my channel to his subscribers and about his channel to my subscribers. Moreover, he said about applying some list-related ideas to improve his channel, and my heart softened.

Simply writing “read such a cool channel” seemed to us an uninteresting activity. This is not what the great owners of big Telegram channels taught us. That’s why we decided to take a more thoughtful approach. Word by word, the conversation discovered that Alexander had been running his household using Scrum for several months. This is where I was hooked. I'm not a big fan of this work organization framework, but I acknowledge its significant impact on the IT industry.

What caught me so suddenly? The fact is that the framework uses two lists to organize work: the Definition of Ready (DoR) and the Definition of Done (DoD). In other words, DoR is the criteria that a task statement must meet. DoD is the criteria that the completed work must meet.

This post will talk about “readiness”, the Definition of Ready. There is a lot of secondary material scattered all over the Internet on the topic of determining readiness, but we will use the primary sources. As such, I see the Scrum Guide [1], books by one of the co-authors of the methodology, Jeff Sutherland, and books by the second co-author of the methodology, Ken Schwaber. I also looked into the books by Jay Jay Sutherland, the son of the original creator. He also wrote about Scrum.

To my surprise, this important list is mentioned in a clear way in only one of the sources, in the book “Scrum” [2]. But it’s okay, for a short analysis this will be more than enough for us.

Although I was aware of the existence of DoR before writing this article, I did not remember that Jeff Sutherland had a very specific list in mind that he recommended for testing the readiness of a user story for development. A user story in Scrum is a work for the team that will result in a noticeable for the user change in the product.

This list was compiled by “Bill Wake, who’s a deep thinker on software design.” The first letters of his points cleverly form the acronym INVEST. Here's what it stands for: Independent, Negotiable, Valuable, Estimable, Small, Testable. The following will be a quote from the Scrum book with explanations of each point:

Independent. The story must be actionable and "completable" on its own. It shouldn't be inherently dependent on another story.

Negotiable. Until it's actually being done, it needs to be able to be rewritten. Allowance for change is built in.

Valuable. It actually delivers value to a customer or user or stakeholder.

Estimable. You have to be able to size it.

Small. The story needs to be small enough to be able to estimate and plan for easily. If it is too big, rewrite it or break it down into smaller stories.

Testable. The story must have a test it is supposed to pass in order to be complete. Write the test before you do the story.

In my practice of building development teams, I came across the INVEST list and even tried to apply it. What advice would I give to someone who wants to use this approach in their team?

Be aware that no matter how smart the designers of various methodologies are, they cannot consider all the contexts in which their tools will be used. Any list that promises to solve something, let alone a methodology, needs to be adapted step by step. Unless, of course, you are in a crisis and plan to use violence for insubordination.

Pick one thing, like valuable. Formulate more clearly what this means in your project, let the team get used to it. Then you can take on any next criterion that looks the most promising. So, step by step, you will be able to make this difficult transformation.

The second part of the article will talk about the acceptance criteria for already completed development, about the Definition of Done.

List of links:
[1] The 2020 Scrum Guide from the Scrum Guides site
[2] Jeff Sutherland, Jay Jay Sutherland, “The Art of Doing Twice the Work in Half the Time”, ISBN 978-1-448166-602