Please login or join to subscribe to this thread
It sounds like the pre-planning session isn't working well as currently structured. Based on my experiences and understanding of agile practices, pre-planning should be a collaboration between the product and engineering teams and involve discussion about the scope items, which would result in a groomed story that has sufficiently documented requirements, the whole team understands the acceptance criteria/definition of done, and the story has been estimated based on the conversations that happened during pre-planning/backlog grooming.
I found this site with 6 tips (including for breaking down sessions to 30-45 minute increments) that I think will help:
This is the problem in sprint-based approaches with waiting till the last minute to do planning for an upcoming sprint. A good practice is "lookahead planning/modeling" which is an ongoing activity the team does to gather info about high priority, near term work items. Of course, this does require access to the key stakeholders (e.g. product team members) other than just during planned events...
Some thoughts from when my PM and engineering team was on the other side of the world from the build team:
- Move your meeting time so that it is closer to business hours for both parties. If it's a 10 hour time difference, one team may come in a bit early for the meeting and the other stays late. If there are meetings well outside business hours for one team, such as to support a manufacturing team, someone needs to be dedicated to support who is knowledgeable enough to take notes and communicate back to their home organization.
- If the meeting cannot address all the detailed level questions, those should be logged and scheduled as working level meetings to tackle individual problems. When running meetings, I spend a lot of focus determining what needs to be discussed before the time runs out, and what needs to be tabled for further discussion.
- If you rush your planning too much, your plan will fail. Be realistic about how much time it takes to evaluate your requirements, and needs of your next sprint. We sometimes complain, "There is never enough time to do it right the first time, but there is always time to fix it later." Don't fall into that trap.
Some of that advice is from doing root cause analysis corrective action of previous issues, so do your own RCCA to determine where your process is broken, define specific improvement opportunities, and work those in sprints too.
Please login or join to reply