Have you drawn your "doable line"?

I often like the backlog to a refinery. In the bottom, you feed the refinery with the crude "oil": vague ideas, big proposals, great plans. As you and your organization work with the items (the goals) the items will eventually turn into useful increments in your product, slowly bubbling to the top.

From an agile point of view almost all backlog items suffer from two things: size and fuzziness. Size, because it is easy to come up with great ideas that also will take a great amount of time to implement. Fuzziness, because it is hard to know what you want.

The refining process for our requirements and wishes (the grooming) is basically about reducing this size and fuzziness. Can we take a slice of the requested functionality and implement into something meaningful during the next sprint? Can we get clear answers to the open questions so that we will know more exactly what we are supposed to do?

In Scrum we never let the Product Owner come to a sprint planning session with an ungroomed backlog: a backlog where the top stories (items) are too big, too fuzzy, or both. This is because such stories aren't really doable. Or: yes of course we can implement them. But not in any predictable manner. We will get stuck in trying to figure out the precise meaning of the requirement, and since the item is so big we won't be able to finish it within the limited time-frame of the sprint.

It will ruin our predictability and thus the ability to plan, as well as it will ruin our morale. The organization will start to feel uncomfortable with our ability to deliver.

It is always better to know early on that an item isn't really doable. We'd rather refrain from trying than fail from trying. Therefore many teams has come up with the Definition of Ready. If the Definition of Done is the team's post-condition (this is what we can promise about anything we have done), the DoR is the team's pre-condition (this is what all items should look like before we accept them into our sprint).

Typical Definition of Ready criteria (or "doable" criteria) includes: no outstanding open questions, and: can be implemented by two persons within the scope of one sprint. These two criteria targets the fuzziness and size directly. Other criteria could include: have an explicit way of testing the item, have the solution reviewed by the operations team, be a proper who/what/why-story (I'll explain later).

The doable criteria serves as a quality assurance of the requirements themselves. We know that we increase the risk if we don't follow them, so therefore we don't accept them into our sprint. We handle them at the grooming sessions instead, until they are refined enough to be considered.

At the top of your backlog, draw a line. This is the "doable" line. All items that fulfil our Definition of Ready may pass that line from below. Everything we plan to include in our sprint is taken from the items above the line. Smoothness, predictability, information generation and distribution, and high quality requirements will be the result.