What should a proper Ready for Sprint definition contain?

Question

Teams in our company deal with Product Owners who are in such a position that they cannot spend as much time with us, as we would like, to do proper Backlog Grooming.

Thus in order to alleviate some of the time constraints we have begun implementing the art of getting stories "Ready for Sprint" or in other words getting them into a state where we know/understand enough to take them into a sprint.

Unfortunately we are still new to what would be a proper definition of 'Ready For Sprint' and so the question of what would be good to keep in mind when getting a story in the backlog Ready for Sprint?

[EDIT]

In response to answers and comments by Ryathal and Donal Fellows i would like to try explain that we do not intend to actually build the stories. We would like to apply the practice of getting existing stories "Ready for Sprint" as explained by this Blog Post. Product owners should probably be adding to this but as mentioned we are not in a prime position with our product owners (as yet).

We have read that you can make definitions such as a story is in Ready state if its effort points are 5 or less, or the story must have Minimum Acceptance Criteria defined, or it must have a Balsamiq Mockup etc.

My question is geared towards finding what others have used in their definitions and what has worked for them. :)

Answer 1

It should contain enough information that, at the end of the sprint, acceptance is not going to be a problem.

Sometimes a single sentence is good enough.

Quite often, some team members will want more information/requirements written down to make sure nobody changes their mind and remembers all that was agreed on.

Anything written down should be as objective/verifiable as possible. I like the 'given/when/then' and 'as ... i ... so that ...' formats quite a lot, as they convey a lot of information and verifiable requirements in a compact form.

I have seen a couple of attempts at defining 'rules' or gates for the different stages in a story lifecycle (ready for sprint, accepted...) - and in my experience rules alone don't work well. It's very easy to end up having an overly exhaustive list of things a story must contain to be considered (use case, tests plan, mock ups, acceptance criteria, documentation, etc). It's very hard to ensure that those items are 'good'. And in many cases (simple stories with a lot of shared context or unsurprising content), mocks, tests plans and details are a waste of time.

An recent example: encouraging 'as X I want to Y', I ended up with 'As an admin, I expect data confidentiality and integrity to be maintained in the platform.' It meets the guidelines, but is completely useless at telling dev what they need to deliver/test/document.

I don't think you can get away from having good communication between PO and dev, and a good feeling about what each side is going to think is good enough.

Answer 2

A story is "ready for sprint" when:

• it contains verifiable requirements and
• you believe it matches what the client wants.

You should also try working with your owner to increase the time they can devote to working with you, and find ways that they can do some backlog grooming on their own if they can't already. The best way to get more involvement is going to be delivering quality with your current level of interaction and explain that further involvement can further improve results.

Answer 3

I think the definition of ready is pretty self explanitory, and not really worth explicitly defining.

If the PO disappears until the end of the sprint (which may happen), and the team build what the story says, is there any way the Product Owner can say 'This isn't what we agreed on'? If not, it is ready.

Depending on PO involvement in the sprint, and the type of story this can be very detailed, or very simple.