Training Retrospective: Scrum Product Owner®

Earlier this month I completed an online training for Certified Scrum Product Owner® certification. Having practiced agile ways of working with an interest in project management since the beginning of my career, I finally committed to get certified as a way to conclude and review my agile experiences, most of which used Scrum. While there are multiple certificates of agile methodologies, I chose Scrum training at the end because it’s the most widely recognized and is currently used by my team. 

Given my team are delivering analytics trainings and that we’ve come up with learnings from our own Scrum practices, I’d like to share my training retrospective here in two parts: delivery and content. Both are interesting and may be used to improve our future trainings and ways of working. 

Content delivery in a time of quarantine 

The Scrum training I participated ran for 8 hours online in two consecutive days of the course. In these 16 hours, it was intensive and challenging for all 13 students and the trainer to remain focused, engaged, and organized in a virtual setting. The successful training was therefore dependent on its content delivery, as well as the following factors. 

  1. The training was paid

  2. The trainer was a full-time training professional with 10+ years of experiences

  3. A certification was guaranteed at completion 

In terms of content delivery, here are 3 key components: 

  • Everyone was asked to keep video camera on as much as possible during the training. 

  • A 7-minute break followed every 45-minute training. 45 minutes for lunch break. A time counter was broadcast on screen during each break. Sufficient time was allocated for Q&A.

  • The interactions in this “virtual classroom” were facilitated with technologies: Zoom breakout rooms and Mural’s virtual workspace.  

Some well thought-through features of Zoom and Mural made the normally offline interactions possible. 

Zoom breakout rooms 

The trainer used this feature to assign students to multiple video chat rooms at any given time for any length of time. My fellow classmates and I were many times randomly assigned so we could work with almost everyone else in the class. 

The breakout time could be ended at the trainer’s discretion. Before a breakout session ended, a countdown timer would pop out on screen and then all would return to the original meeting room.  

Mural virtual workspace 

In addition to slide presentation screen-shared during the webinar, most of the exercise materials are stored and organized in Mural.  

It is like a white wall where participants can create post-it stickers and vote on the post-it stickers simply by dotting/clicking on them. Each wall is a webpage, which can easily link to other pages. Links can be locked/unlocked by trainer to, for example, prevent spoilers for upcoming exercises/content.  

Realtime actions and movements by participants are shown on screen – either anonymously or with usernames if logged in. Pages can be zoomed in/out easily. UX is simple and intuitive. 

The content: what, how, when, who of Scrum 

My key takeaways / demystified concepts from this training: 

  • Scrum is essentially a framework of ways of working. It requires (not just allows) collective agreements on specifics among the Scrum team to make it work. It doesn’t answer or define the details.  
    For example, how points are calculated, how daily scrum/stand-up is run, how much participation the team needs from a scrum master.  
    I’d say it’s a 50% defined framework that requires 50% active team engagements to complete the ways of working. 

  • The biggest learning from this training to me, however, was about roles and responsibilities among product owner, development team, and scrum master.  
    Product owner takes the accountability and navigates the vision and stakeholder management.  
    Dev team owns most responsibility and the essential daily operations.  
    Scrum master should/better be someone who understands dev team, and thus is better filled in by internal resource. This role can easily be taken by someone from the dev team, as it typically requires about 10% of a person’s time.  

  • Another learning is on the distinction between scrum product owner and a project manager. In a broad sense, to me, a general/traditional project manager combines both product owner’s and scrum master’s roles.  

  • Organization structure is essential to the success of agile practice. Agile doesn’t happen just because there’s an intention, a scrum master (+product owner +dev team), or an agile training course taken.

  • Not every project is fit for scrum. Some projects can be run in a general/traditional project framework or other frameworks like waterfall. Scrum is ideal for non-physical products that can continuously deliver value*. For example, software, websites, apps (like Zoom, Office 365 suite).  
    *continuously deliver value: in that product increments (enhancements) are/can be delivered after every sprint 

Q&A: 

  • Is scrum master necessary?  
    --> No. It’s a good to have role that can help induce project efficiency by enhancing understanding of WOW and backlog management, facilitating Scrum events, fostering team rapport, and coaching team individuals, etc. The role itself is powerless and doesn’t produce deliverables. 

  • Ideal size of a development team? 3 to 10 people, but 3-5 are the best. 

  • Should a ticket’s points be measured by its delivered value or by its efforts?  
    --> Efforts. If a ticket is measured by its value or complexity, then the point of estimating workload in a given sprint (e.g. 2 weeks) is missed.  

  • Should idea tickets be kept in the Incoming/Idea stage of Kanban or moved to Backlog stage?  
    --> There’s no value in queuing Backlog. Once a ticket is moved to Backlog, it’s placed with a commitment of doing it. So an idea or upcoming activity is best kept in Incoming unless the team is committed to get it done. 

  • Should a ticket’s due date be changed/updated to a new day or kept as originally planned so to measure the delay? 
    --> Scrum framework doesn’t define/regulate this. Also, due date is not a mandatory field in a ticket (though we always aim for / specify a due date). Change of due date can reflect our new ticket prioritization, so there’s little point keeping the original due date. 

References and resources 

Final thoughts 

On Scrum: at the end of the day, these ways-of-working practices and frameworks are devised to enable efficiency and clarity for projects. A team can still be agile by adopt parts of Scrum/other methodologies’ practices without having to 100% follow a single framework. JIRA tickets are in my opinion the fundamental for all teams because it contextualize the invisible tasks, workflow, progress, etc. better than shooting emails around.  

On content delivery: for any webinar trainings or longer meetings, we can definitely benefit from testing new technologies to deliver better training programs/workshops online. 

Evelyn Chao is a digital marketing professional based in Lausanne, Switzerland. She has worked at Philip Morris International, In the Company of Huskies, Big Spaceship, Renegade, Museum of Fine Arts, Boston, and American Public Television. Her analytics works and research have served global accounts, including IQOS, Google Play, YouTube, Samsung Mobile, Guinness Storehouse, Fáilte Ireland, and Empire State Building.