Tip #8: Assign action items for any big risks or unknowns
For big requirements issues, this probably means assigning the issue to the PO. For big technology risks or unknowns, this means assigning a dev team member to research the issue at hand. The person assigned should be ready to report on the action item at or before the next grooming meeting or definitely before or at the Sprint Planning Meeting. This will usually involve re-estimating the item based on the new information — and that’s perfectly acceptable.
Tip #9: Remember that backlog items (and/or User Stories) are a collaboration between the PO and the team
The final responsibility for making sure the PBI’s are adequately detailed for the development team’s use falls on the Product Owner. However, don’t take that to mean it’s the PO’s job to do all that work. The items should be the results of a collaboration between the PO and the team(and also probably between the PO and the customers or end users). It is perfectly acceptable, and in fact encouraged, that the PO meet with 1, 2, or all members of the team to help detail a PBI, prior to a grooming session (what I call “informal backlog grooming”). Schedule meetings or have spontaneous collaborations as necessary, with the end goal being a well thought out, well detailed PBI when it is presented at a backlog grooming session. It is very atypical for a PBI to be one that is new to every single developer at a backlog grooming session. If this happens, consider it a bad smell and try to get developers involved earlier.
Tip #10: Remind the dev team to review the PBI’s to be discussed about 24 hours prior to the grooming session.
If your PBI’s are documented in any way before a backlog grooming session (such as on a wiki or on index cards), send a reminder to the dev team to review them so they are prepared to speak intelligently about them.
If the PO is making lots of last minute edits right up until the grooming session, much of the information will be seen for the first time in the meeting, which can make the meeting last longer. Ideally, the PO should target their editing efforts at being ready 24 hours prior to the backlog grooming session.
Tip #11: Feel free to split PBI’s during this meeting.
If anyone on the Scrum team feels the need to split items, during a grooming session is a perfect time to do it. You’ll probably want to re-estimate them too, and that’s fine. I hope it also goes without saying that if you split an 8 point PBI there should be no emphasis on making sure that the split out PBI’s all up to do 8 points. Just re-estimate them as if they were new, independent, PBI’s.
Tip #12: Optimize your time in the meeting.
For PBI’s that are well defined, just discuss and quickly estimate. For PBI’s that have already been discussed in a previous grooming session, you only really need to revisit them if there is new information about them. For PBI’s where there is new information, just discuss the new information enough to be able to give a new estimate.
Tip #13: Don’t be afraid to discuss a couple of items that are farther down the backlog
Sometimes there will be a need to discuss a backlog item that is further down the backlog in priority. Here are some reasons for doing that:
- The PO needs to gauge the rough size of a PBI
- The dev team needs to identify external dependencies that will need to be started on ASAP while waiting for the rest of the item’s details to be flushed out.
There can be many other reasons, too. While we don’t want to get into a habit of doing BRUF(Big Requirements Up Front) or BDUF(Big Design UP Front), thare are rare situations where looking at a backlog item that is farther down the road is advantageous to the team and the organization as a whole. Don’t be afraid to do it, but be wary of slipping back into BRUF and BDUF.
Tip #14: Strongly consider doing some informal backlog grooming before the full team backlog grooming.
- Informal Product Backlog Grooming
- The Product Owner will work with zero or more dev team members or stakeholders to refine stories and their priorities. Said another way, this is a lighter more informal way to groom the items in much the same way the grooming is done in the Weekly Team Backlog Grooming. This kind of informal grooming should be a daily, if not hourly, occurrence for the Product Owner.
- When the PO gets together with development team members(early collaborators), she should strongly consider making sure that the three amigosare there.
- Also feel free to bring stakeholders in to discuss.
- Development team members should feel free to discuss relative sizes with the PO, but I encourage teams to wait to record any estimate until the entire team has estimated the item first. Said another way, the early collaborators should try not to skew the entire team’s estimates.
- When the PO gets together with development team members(early collaborators), she should strongly consider making sure that the three amigosare there.
- The Product Owner will work with zero or more dev team members or stakeholders to refine stories and their priorities. Said another way, this is a lighter more informal way to groom the items in much the same way the grooming is done in the Weekly Team Backlog Grooming. This kind of informal grooming should be a daily, if not hourly, occurrence for the Product Owner.
Tip #15: Don’t be afraid to introduce late breaking PBI’s. Try to minimize them, but embrace them when they happen.
Remain Agile! Some of the major goals around doing backlog grooming are to reduce unknowns and risks, but not all risks are easily identifiable before hand. Backlog grooming is not meant to eliminate risks, only to minimize them. Late breaking PBI’s will probably still happen(hopefully rarely), and they should generally be welcomed by the team. On the other hand, if it seems like most of your backlog items are late breaking, that is generally a bad smell.
Tip #16: Meeting Attendees: The entire Scrum Team + rare appearances by other key people
The meeting attendees should be, at the minimum, the entire Scrum Team. On rare occasions, you will need other key people, but prefer keeping non Scrum Team members(aka chickens) out of the meeting as a general rule. From time time to time, it will be useful to have a non Scrum Team member appear, but even those appearances should be limited. Try to limit the “other key people” to only attending while the relevant backlog items are being discussed.
Conclusion
If backlog grooming is done well, you can skip the entire “What” part of the Sprint Planning meeting and go straight to tasking out PBI’s in the “How?” part of the meeting. How’s that for a short planning meeting? Most teams will find that having regular product backlog grooming increases overall team knowledge and eventually increases productivity, usually by a large factor.
Link to Full Article:
Tips For Effective Backlog Grooming
What your backlog grooming tips? Post them in the comments.
Related articles on ScrumCrazy
- Why do Product Backlog Grooming?
- What does Product Backlog Grooming Look Like?
- The Bradley User Story Maturity Model
- User Stories: Best and Worst Practices
- I wrote a skit for a presentation I did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read the script of the skit here:
Related articles on the web
Filed under: Product Backlog, Product Backlog Grooming, Product Owner Tips, Scrum, ScrumMaster Tips, The Scrum Artifacts, The Sprint Time-boxes |
The Scrum Crazy Blog 
Leave a comment