Jeffry Hesse wrote this blog post. And it inspired me to write the post below.
The new Scrum Guide says that PBIs (product backlog items) must be well-understood and granular enough (just before going into) for Sprint Planning. And that PB Refinement is the process we use to get them to Ready.
Those are not quotes, but that is how I read it. I think accurately.
Jeff Sutherland and I and others advocate the 'ready, ready criteria'. Roman Pichler and others call it the Definition of Ready. I am ok with either phrase.
So, what is it?
Well, like the DOD (definition of done), it must be specific to each Team. Each Team must define one for themselves. And they vary some, depending on many factors.
We want the User Stories (or PBIs) to be more defined than they often are for some 'agile' teams. But this does not necessarily mean the voluminous documentation that many waterfall 'teams' have. (I put 'team' in quotes here because I never find that waterfall teams have anything close to the team feeling of agile teams, especially a good agile team. Nor the productivity.)
So, 'ready' is kind of a Goldilocks concept (like most things in life): not too little, not too much, just right. A balance. We definitely want to leave some room for the Team to be creative during the Sprint.
The ready, ready criteria are similar to the concept of GIGO. Garbage In, Garbage Out. Or rather, obviously, the opposite. We want 'good stuff' going into the Sprint, so that 'good stuff' can be completed at the end of the Sprint.
I conduct courses and workshops all the time, and I ask people: what do you want in your 'ready, ready criteria'? The context is: Imagine we are having a short meeting about 1.5 days before the Sprint Planning Meeting. What are the things you want to review to be sure the 'top items' are ready, ready? And we assume a 2 week sprint, with about 8 small PBIs (stories) about to go into the next sprint. (Yes, I am making lots of assumptions that may not apply to you...)
Here are some of the things they say. This is a super-set. First, any list would not apply to 'every' user story you have. Second, for your specific team, you might make this list longer, shorter or just different. Suitable for your specific situation.
So, here are some of the things I recall them saying (that I agreed with):
If a couple of stories get rejected, the PO has another day to 'get his stuff together' to get them ready for the SPM (sprint planning meeting).
This meeting is one of the two meeting I like to have to do Release Plan Refactoring. This one is short-term focused. The other is 'long-term' focused. These two meeting go together. We do not have one without the other. We plan longer-term so that Sprints go better. We do Sprints to fulfill the longer-term Vision. They go together.
This meeting (just before SPM) requires that the PO 'get his stuff together' beforehand. For example, the acceptance criteria should already have been defined, and the question is: does the Team think they work?
And not all that work is done by him (or her) alone. But the PO is responsible. It is expected that a few issues will be found. The POs work is expected to be good, but not perfect. (Again, it is not solely the POs work; many others could have contributed.)
We have the assumption that every day we are learning, and every day things can change. Both for the good and for the bad, and for the 'bad' (eg, maybe good for the customer, but harder for us as a Team to deliver). Hence, we have to have this meeting at the last responsible moment. (Cf. the Poppendiecks.) Just before the next sprint planning meeting, leaving some time for the PO to recover from some issues.
Are some of the issues or concerns above being addressed on other days during the Sprint? YES! By the PO. In some one-off quick meetings. In some pairings, maybe with business stakeholders. Etc. Etc. Etc. But this is the last time where the whole Team (together) reviews the stories about to go into the Sprint. It should be a fairly short meeting (about 1 hour).
Or, so I coach for most teams.
Are there other ways to do it? Surely. Are they more or less successful? I don't really know -- I have not tried all the million other ways. I see my teams having more success with my approach. But honestly I do not have double-blind independent studies. Do you?
***
Two points additional points:
The Team must be motivated to do this. And I would try to include some business stakeholders. By giving the Team the 'thumbs up?' vote, that tends to get their attention.
In a 2 week Sprint, I also like to do another meeting, in the first week, that addresses the Release Planning for the longer-term. That meeting is also typically about 1 hour. More on that later.
***
I hope you will give feedback. I hope you will try some of these ideas, and that they help you. And then give feedback again.
The new Scrum Guide says that PBIs (product backlog items) must be well-understood and granular enough (just before going into) for Sprint Planning. And that PB Refinement is the process we use to get them to Ready.
Those are not quotes, but that is how I read it. I think accurately.
Jeff Sutherland and I and others advocate the 'ready, ready criteria'. Roman Pichler and others call it the Definition of Ready. I am ok with either phrase.
So, what is it?
Well, like the DOD (definition of done), it must be specific to each Team. Each Team must define one for themselves. And they vary some, depending on many factors.
We want the User Stories (or PBIs) to be more defined than they often are for some 'agile' teams. But this does not necessarily mean the voluminous documentation that many waterfall 'teams' have. (I put 'team' in quotes here because I never find that waterfall teams have anything close to the team feeling of agile teams, especially a good agile team. Nor the productivity.)
So, 'ready' is kind of a Goldilocks concept (like most things in life): not too little, not too much, just right. A balance. We definitely want to leave some room for the Team to be creative during the Sprint.
The ready, ready criteria are similar to the concept of GIGO. Garbage In, Garbage Out. Or rather, obviously, the opposite. We want 'good stuff' going into the Sprint, so that 'good stuff' can be completed at the end of the Sprint.
I conduct courses and workshops all the time, and I ask people: what do you want in your 'ready, ready criteria'? The context is: Imagine we are having a short meeting about 1.5 days before the Sprint Planning Meeting. What are the things you want to review to be sure the 'top items' are ready, ready? And we assume a 2 week sprint, with about 8 small PBIs (stories) about to go into the next sprint. (Yes, I am making lots of assumptions that may not apply to you...)
Here are some of the things they say. This is a super-set. First, any list would not apply to 'every' user story you have. Second, for your specific team, you might make this list longer, shorter or just different. Suitable for your specific situation.
So, here are some of the things I recall them saying (that I agreed with):
- Is the US (user story) phrased well and completely (eg, the 3 parts)? Do not forget the 'so that' clause.
- Does it match the INVEST criteria well? (You remember them: Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable.)
- Small enough? (Sized appropriately should have done that, but let's emphasize that one. A key issue for most teams -- stories are not small enough yet very often.)
- Acceptance criteria good? (These should cover the tests well enough. If not, add another item.)
- Story points still good?
- Business value points still good? (Relative business value points. Explained elsewhere.)
- Questions answered? (Reasonable questions from the Doers.)
- Tech Issues addressed? (One simple example: Android, iPhone, Windows Phone or all 3?)
- Enabling Spec good enough? (A whole other discussion. Not for now. The blog has a post on this.)
- People-work match? (Sometimes the PB has all Java stories for this sprint, but there is only one Java guy in the Team, and he is going on vacation for a week. Yikes! Mis-match!)
- We still agree this is the best work for the next Sprint? (Best considering everything, but especially business value.)
- Team Thumbs Up? (I want everyone on the Team to give each story a thumbs up. This is a catch-all; if something is amiss that is not covered above, hopefully someone's thumb catches the issue.)
If a couple of stories get rejected, the PO has another day to 'get his stuff together' to get them ready for the SPM (sprint planning meeting).
This meeting is one of the two meeting I like to have to do Release Plan Refactoring. This one is short-term focused. The other is 'long-term' focused. These two meeting go together. We do not have one without the other. We plan longer-term so that Sprints go better. We do Sprints to fulfill the longer-term Vision. They go together.
This meeting (just before SPM) requires that the PO 'get his stuff together' beforehand. For example, the acceptance criteria should already have been defined, and the question is: does the Team think they work?
And not all that work is done by him (or her) alone. But the PO is responsible. It is expected that a few issues will be found. The POs work is expected to be good, but not perfect. (Again, it is not solely the POs work; many others could have contributed.)
We have the assumption that every day we are learning, and every day things can change. Both for the good and for the bad, and for the 'bad' (eg, maybe good for the customer, but harder for us as a Team to deliver). Hence, we have to have this meeting at the last responsible moment. (Cf. the Poppendiecks.) Just before the next sprint planning meeting, leaving some time for the PO to recover from some issues.
Are some of the issues or concerns above being addressed on other days during the Sprint? YES! By the PO. In some one-off quick meetings. In some pairings, maybe with business stakeholders. Etc. Etc. Etc. But this is the last time where the whole Team (together) reviews the stories about to go into the Sprint. It should be a fairly short meeting (about 1 hour).
Or, so I coach for most teams.
Are there other ways to do it? Surely. Are they more or less successful? I don't really know -- I have not tried all the million other ways. I see my teams having more success with my approach. But honestly I do not have double-blind independent studies. Do you?
***
Two points additional points:
The Team must be motivated to do this. And I would try to include some business stakeholders. By giving the Team the 'thumbs up?' vote, that tends to get their attention.
In a 2 week Sprint, I also like to do another meeting, in the first week, that addresses the Release Planning for the longer-term. That meeting is also typically about 1 hour. More on that later.
***
I hope you will give feedback. I hope you will try some of these ideas, and that they help you. And then give feedback again.
1 comment:
I like this blog :)
Post a Comment