Depending on your particular implementation of agile, this power may be necessary for either your story sizing sessions or your main sprint planning meeting. Either way, it can be rough and you will very likely get hazed by the development team on your first outing.  This can help…

If you are new to your role and especially if you are new to agile (coming from waterfall), the first time you walk into a planning session the developers (and you!) may be a bit anxious.  No requirements docs, no detailed specs.  Just a simple backlog of stories…and you.  To compensate, the team will be asking a lot of questions.

You, fearless product owner, will of course do your best and you can survive your first planning meeting if you have these four shields at the ready:

1. Prepare(!) – This is all important once you know what it means, but basically you have to really ‘get’ what the customer’s intent is and describe it clearly in your acceptance criteria.  If you don’t make it clear, the developers will say things like, “We can’t build this without more specific information,” or they will size it as WAY bigger than it really is because of the uncertainty.

2. Be decisive – As the one giving direction for the product, you need to make confident choices when presented with multiple ways forward. If people start discussing two technical paths, pick one and offer that we should size that one.  You will get it wrong sometimes but better to be wrong and learn than to suffer the ‘paralysis of analysis’ (where you may also get it wrong but will take longer to figure that out!)  Just use your best judgment when you weigh the costs and benefits of the options.

3. Size both – I occasionally even have them size two options if: (1) I have a dispute among the team members that is not resolving itself or (2) there is a real chance we might do either and I could benefit from understanding the relative cost difference.

4. Defer – This is your last resort — if you run into a story you THOUGHT you prepared well enough but turns out you didn’t, don’t be shy about deferring it until a later time it so you can clarify. Ain’t no shame in it.  Say it with me, “I think I need to clarify this story a bit more.  Let me do that and bring it back around next time.”

I won’t lie, I have been raked across the coals by two development teams and each of my product owners were by their respective teams as well, even though these are all fine teams of reasonable people.  Seems to be a right of passage, but if you use the techniques here and act with confidence, you’ll be fine.

Would love to hear your ideas, and don’t forget to join me next week for Super Power #2 – Selling (your ideas), same PO time, same PO channel.