2

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. :)

  • I'm more than a bit hazy about this, but isn't the point of a Product Owner that they're there to provide on the spot direction? Maybe you're labeling the wrong people as POs and should instead have someone on the team who acts as the customer's representative… – Donal Fellows Jul 23 '13 at 12:28
  • I fully agree with you on what the PO should be about. :) Unfortunately we are in the process of teaching the company about Scrum&Agile (as is always done it seems) and so we have been "given" those who are best suited to play the role. As developers, we are trying to add more value from our side to help "guide" them to becoming what they should actually be. – David 'the bald ginger' Jul 23 '13 at 13:09
2

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.

  • Thank you for the answer. I think you are describing the actual building of a story? Our product owners do work on the stories but we would like to add more .... 'quality' through applying a definition of ready. I have amended my question with some motivation for the question. – David 'the bald ginger' Jul 26 '13 at 5:10
  • Sorry about that. I augmented my answer. – ptyx Jul 26 '13 at 16:01
  • 1
    Also, one thing I've found helpful with new POs: have the scrum master seat with them at least a week in advance, reviewing the stories they plan for next sprint and working at making them 'good stories'. It's not wasting the team time (that's NOT something you want to do in planning meeting), and goes a long way educating both the POs and the SM about each other's needs. – ptyx Jul 26 '13 at 16:04
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.

  • We are trying to add additional value to stories through getting them "ready for Sprint" so that the PO can see it and understand the value of what they could/should be doing. :) – David 'the bald ginger' Jul 23 '13 at 13:11
  • 1
    @logansama getting stories ready for sprint is more extra crap you have to do to get real value added, the value you need to show is delivering completed stories in a timely manner and iterating quickly on those not matching what the client wanted – Ryathal Jul 23 '13 at 13:16
  • @Ryathal " getting stories ready for sprint is more extra crap"? are you saying that it is a waste of time to get an accurate understanding prior to starting, but it is NOT a waste of time to have to rework it because what you created did not meet expectations? Hmmm. That doesn't sound like a good use of time. – Curtis Reed Feb 28 '18 at 20:49
  • @CurtisReed it's a balancing act, stories need to be groomed to the point developers and the PO understand what is going to be done with them. This may or may not actually meet their expectations, but now you are in a position to iterate and more clearly define those expectations. Spending tons of time grooming a story to be perfect is how you turn an agile process back into waterfall. Your unknowns usually only become knowns when you start doing things, so you can address them directly. Guessing at unknowns usually means rework and wasted planning time anyway. – Ryathal Mar 1 '18 at 13:03
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.