1. Never schedule BGM during the first 20% or last 20% of the Sprint or iteration
During the first 20% of the Sprint, the team is just getting started on this Sprint's work, so you'll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that's not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog grooming
2. Treat BGM like the first part of sprint or iteration Planning Meeting
This BGM is often called as the “What” of the planning meeting. The Product owner presents the user stories/backlog items to the team. Backlog items are clarified to team and then team estimates each item. The priorities might change based on the estimates.
3.Present enough work to last about 2 Sprints or iterations beyond the current sprint.
There are 2 reasons for this.
- If more PBI (Product backlog item) is de-prioritized, there must be enough work leftover to fill an iteration or sprint.
- It is also a good practice to have some of finely groomed PBI’s beyond what you are working on in a print in case someone frees up and need more work.
4. The backlog items must have an initial set of acceptance tests defined before the meeting occurs
Even if the initial acceptance tests are high level, that is better than no acceptance tests at all. The more the PO and team focus on getting to good detailed acceptance tests, the better.
5. Estimates are not final until a PBI/story has been accepted into a sprint.
Do not let the team stress out too much on the estimates since the team is just getting a preview of the PBI's. Acknowledge the team that the PBI's estimate is not final until the PBI has been accepted into the sprint or iteration. Team members are free to bring any new information up and re-estimate the PBI.
6. Product Backlog order is not final until a PBI has been accepted into a sprint.
The PO can change the backlog order between BGM and Planning session. But make sure that the changing order too frequently might frustrate the team.
7. Keep an eye on meeting goals
- The team must have enough work queued up for next iteration/sprint & team must be confident about their upcoming work.
- Any major questions or concerns must be answered/addressed
- The risks must be identified and high level mitigation plan must be in place
8. Feel free to split the PBI’s during BGM
Do not keep PBI with more than 8 points. Split the fatty PBI and re-estimate them as if they are new and independent PBI.
9. Experiment with amount of grooming that the team does
At initials stages you may need more grooming sessions until your team is 2 iterations ahead. The usual time box for grooming is 10% of the development time in the sprint or iteration. But there are no hard and fast rules. Experiment with the time box and find out comfortable BGM duration for the team.
10. Retrospect, Inspect & Adapt
It is much important that the team inspects and adapts their practices. If team feels that the BGM is waste of time, then there are hidden impediments that should be removed at once. It is
recommended to do 5 why’s analysis for better backlog grooming sessions.
No comments:
Post a Comment