Garbage In, Garbage Out;
Why Definition of Ready Matters
Author: Tomasz Korzeniowski
By failing to prepare, you are preparing to fail. Benjamin Franklin
It’s been more than two centuries since Benjamin Franklin mouthed that simple truth which is the basis of GIGO (Garbage In, Garbage Out) computing principle.
Ranking, prioritizing, and seasoning with a good deal of clear communication and teamwork: a neat user story goes a long way from being passed along by a client to the Product Owner in bits and pieces to be then painstakingly knitted together into one structured piece of work, included in the sprint, and turned into a scrummy feature of the customer’s product. Let’s follow its lifespan and find out what a ready user story that is delivered spot-on in one sprint should look like.
Why is it so important?
SCRUM is a flexible methodology where being ready is fundamental to succeed. The term “ready” was first coined by Ken Schwaber and Mike Beedle in their book on SCRUM. Only a “ready user story” can be taken into a sprint and worked on by the development team to become a part of the product increment.
If a user story lacks consistency, the GIGO principle will most probably pull in, and you will get a messy piece of work in the end, irrespective of how good your team is.
Therefore, the PO needs to do their best at translating a backlog item into an accurate communication instrument to get a user story that will come out as an actionable software piece. Let’s sort out why.
Bridging the gap between ready and done
During backlog grooming the PO — checking it with the development team — sets priorities and ranks items that will be included in the sprint. A collaborative effort and efficient teamwork play a vital role in being able to tell what should be marked as ready for what is not that important at the moment or from something that is too big for one sprint and needs to be divided into two parts.
Apart from identifying the right size of the assignment, it is necessary to make the story clear by adding acceptance criteria and performance criteria (where applicable) to have a shared understanding of the user story aims. SCRUM adepts say that three to five well-defined acceptance criteria are enough to make the story testable.
The PO — the company’s focal person and the voice of the client — is responsible for all of it. A lot of questions on customer requirements (ie, what should it look like?; what functionality should it possess?; how should it interact with other elements of the app?) are asked to make it happen and give the development team a green light so that they can start making done out of ready.
It lets the team members know that the user story is feasible and help developers minimize the time spendings and get actionable software delivered on time.
Defining ready
And though it isn’t right to strictly define ready as it will probably vary in different companies, each ready user story should have certain exact things. Below you can find a checklist we use to verify if the user story is ready to be put in the backlog:
Having a ready user story by no means completely insures you against possible slips or loose ends that may loom up during the development process.
The Definition of Ready functions as a contract under which both the PO and the Team know that there’s no garbage in the backlog and each user story is ready to become a valuable feature of the client’s product every single time.
