Scrum Master’s Diary
Sprint 87, Day 4
Sprint goal: release version 4.3.0.
The stage
It’s that lovely time when my team is releasing a new version of our product. Few small features there, additional testing here, polishing documentation and site content over there – no pressure, no death march, sustainable development. And then Dave, our tech lead, announces we have a bug in that very important feature that affects our (very important) old customers. No time for full fix by the end of the sprint. All eyes turn to Patrick, our PO.
Conversation could be summarized as follows:
Have you been in similar situation, as a SM, PO or a Developer? What did you do? Write down those answers! Done? Good. Now let me share some inside information and see if you would change your answers.
Behind the scene
As, a Scrum Master, I have always pushed developers to protect the code quality. Dave was also particularly defensive of the code quality because of his past experience. The Project Manager had forced the team to produce low-quality code. This made adding new features and understanding the code very difficult at times.
Patrick is our new PO, still under a watchful eye of the Project Manager. He is very defensive of his position and his hard-earned autonomy to decide what goes into a sprint or a story.
Our release planning process was roughly to (1) set the release date, (2) pick epics for the release, and (3) cut epics into stories. The problem in previous releases was that during sprinting, new stories would emerge and initial scope of the epic would almost double in size. Since there would be no time for planned epics, PO would either (a) shift the release date or (b) cut the entire epic of the lowest priority. Both, high and low-quality stories would get into the release in both cases, which is not good. The goal is to get only high-value stories into the release, on time. This is why the PO should trim all low-value stories from all epics, while keeping the release date – and that is what I wanted to teach him.
Retrospective
Now, back to the sprint. Release was successful – excluding the incorporated bug, of course. Demo is over, time for the retrospective.
It was clear to me that Patrick, our PO, had trouble differentiating scope cut from quality cut. We had a story with several acceptance criteria, and one of the criteria was related to compliance with older software versions. Not meeting this criteria meant that some of the old users may experience a serious bug. He really had two options if he wanted to keep the release date:
- To cut the story out of the sprint entirely (scope cut), or
- To ignore the bug, and jeopardize the quality and user experience of the whole product (quality cut).
Under pressure to meet the deadline, Patrick picked the second option. He did not even consider the first one – which is a behavior common to traditional thinking (these are the features, get them ALL done).
As a Scrum Master, I needed to show him, and the team, what the options are and what the difference is. I initiated the discussion about the conflict Patrick and Dave had. I guided them to explore each other’s motives for their behavior from the last sprint. This is when I asked them the difference between quality cut and scope cut. Dave knew. He pointed out that Patrick had another option – to cut the whole story out of release and provide hot-fix next week. Eventually, PO and the rest of the team learned.
End results:
- Stronger PO role
- PO learned the difference between the scope and quality cut
- PO wants to learn how to integrate value driven decisions in our release planning process
- Developers understand the PO role better, and how they can help him
Takeaways
- Value oriented decisions and scope cut is hard, help your PO.
- Sometimes, you have to let the team “fail” in order to create a learning opportunity.
- People’s behavior is influenced by their previous experiences and their job roles, not just their personality – keep that in mind.
What do you think? Have you been in a similar situation? How did you react?
