Blog Article Detail

Scrum Master (SM) and Product Owner (PO) – A match made in heaven OR couple from hell

Written by Nawaz Butt on Dec 30, 2019

It's proverbial but true that husband and wife are the two wheels of the same cart. Hence, both need to co-exist, make adjustments and at times compromise (let go) for the betterment of the family. Same can be said for couples in a relationship. Point understood. Then? You must be wondering, where am I going with this? What the heck your personal life has anything to do with Scrum/Agile projects? Let me explain, the same companion role on your Agile project is called 'Scrum Master' and 'Product Owner'. There're some of you who're scratching their heads thinking 'What if the SM and PO be the same person?' Well friends, that's a topic of discussion for some other day. Coming back to this topic, if both (yes they're a different person :)) are in a healthy and strong partnership, the team benefits, and if they entangled themselves in a turf war, the team suffers.

As the focus of my article is not create boredom by going through duties/responsibilities of a SM and PO as outlined in Scrum Framework guide, rather I'll be mentioning 3 challenging situations that are faced on the project and how a couple from hell (Blamers) and a match in heaven (our perfect pair) is going to react and find resolution to those issues.

Situation#1: "Product backlog is not ready or stories not refined enough at the kick-start of the sprint"

Blamers: SM would hold PO responsible for this situation as ultimately he's (PO) the one who enters user stories in the tool and he (PO) should've known that the user stories on the backlog available right now are just mere no more than a title. Probably, Sprint planning meeting would be cancelled for a later date/time. Its' a great opportunity to settle an old score. Ego would kick in and SM would do the right thing (at least according to him) by escalating this issue to senior management.

Perfect pair: SM would show empathy and let the PO present and discuss the half-baked user stories (even there's a danger of producing a wrong output). Some assumptions would be taken. Contingencies (10% +- effort) would be made when estimating effort. Further, PO and SM would work with the team to devise/revise user story 'Definition of ready' that would define all the pre-conditions i.e. acceptance criteria, UI mockups for a user story before it's to be presented to the team. Also, PO would ensure inviting stakeholders in the coming Sprint Review meetings so their feedback can be incorporated early in the Product Backlog.

Situation#2: "Making changes (adding requirements) to the user story during the sprint"

Blamers: A scrum hardliner SM would push back this request as he thinks firstly this is PO's fault of not capturing all the details (now he has to pay for it) and secondly and more importantly it would jeopardize the scope/goal of the sprint.

Perfect pair: SM would try to understand the rationale of the change. And get to work with the development team to assess the impact of the change and effort involve. The PO likely be provided with multiple options depending on the magnitude of the change e.g. if the user story hasn't been worked on yet so to replace it with another user story of equivalent story points or finish the modified user story but remove a user story out of the sprint backlog (equal to effort involve to incorporate the change) or in a worse-case scenario should the sprint be cancelled. It would be the PO to decide whether or not to actually cancel the sprint.

Situation#3: "Sprint items taking longer than expected"

Blamers: PO would suspect team's commitment towards delivery; probably would demand more commitment (extra hours/OT) from the team while SM would try to dig into some underlining facts (stories too big, aggressive estimates, Added scope) to justify this situation. Likely system demo would be cancelled.

Perfect pair: PO would 'open-mindedly' work with the SM and team to understand the underlining issues (highlighted in the team's feedback during retrospective). If stories are found to be huge, SM and PO would work together to slice them into more smaller increments of work or if the team is fairly new to using Scrum; PO would adjust his delivery expectation for at least next 2-3 sprints as it may be due to team's initial velocity. And ya! PO would let the team demo whatever they've finished during the sprint.

There could be numerous typical (aforementioned) and atypical situations on your Agile projects and it's okay for any SM, PO and Team to react to them in there own unique way. After all, Agile is all about adaptability, experimentation and collaboration. Just remember one thought, SM and PO roles are considered as "Leadership" roles in Scrum so they better act like ones.

P.s: - No! SM/PO do not need to go on a date with each other but a professional meeting over a cup of joe which can help sort out differences on the project why not :)