Scrum is a mindset, I guess we all know that by now. It does not consist of standard templates and unbreakable rules. Over time (10 years now) I did found a number of principles for me, as a Product Owner, to work according to within the team. Please do note that I say within and not with. I consider the Product Owner part of the team, of course with a specific role, but without a doubt part of the team. I guess that could already be called the first principle. So.. my 10 golden principles:
- Stories are always discussed in a grooming session. During this session the subjects are functionality, who will do it and why. If it needs to be broken down in sub-stories, how it fits in the greater goals. And equally important, the team will tell what relevant extra information is needed (call them acceptance criteria if you want) . This is extremely important, since the architecture and code determines for a great deal the scope of these questions.
- Stories that have not been part of the grooming session will not be part of sprint planning (of course, there are emergencies)
- If during a grooming session no questions are asked, a story is not understood.
- If during a sprint you have no interaction about a specific story (additional questions, show intermediate results) there is a big change you will not get what you want or in a second case, something is seriously wrong. Check what is going on!
- Your team members are your partners, use them as sparring partners, also about functionality.
- Never demo functionality that you have not seen prior to the demo. It is not the moment to be surprised. And knowing the outcome of stories allows you to prepare stakeholders.
- Never end the day with open questions of your developers on sprint items. You will block your team from a successful sprint. If for whatever reason this does happen, be clear about being the cause. Now do keep in mind that the greatest characteristic of scrum is its error tolerance. So if you provide the wrong answer or make the wrong choice, it can be corrected in general in the next sprint at a price of a few story points. Better take that risk than letting a sprint fail.
- You are always available to the team. I always say that any team member can contact me 24/7 if the questions are relevant for a successful sprint
- Go out together for a beer or dinner, it is really important to build up a real relationship.
- Finally… Product owner is functional responsible. This means that any functionality that comes out of a story is the Product Owner’s responsibility. You can never blame at the demo a developer for not understanding the story.