Tip of the week by Scrum Master Eino: Act as a salesman

Hi, this is Eino here. I am a developer at Wunder, but in most cases, I fill the role of a Technical project manager and a Scrum Master. In my opinion, Scrum Master (SM) helps both the team and the Product Owner (PO) to follow Scrum’s agile concepts. It’s SM’s job to help remove obstacles and facilitate the team to achieve the goal of each sprint.

Without SM, there’s a greater chance for the team to get distracted on what to do, where to get help if one is stuck, and how to plan and achieve daily, weekly, and sprint tasks and goals. As well it is important that PO can efficiently address to the team – what is needed, what is important right now, and how to plan ahead on a longer timescale.

I love being a Scrum Master. There’s always something that I can improve to help my team (both developers and product owners) succeed even better. There are always challenges up ahead, and it gives me a certain satisfaction to tackle them.

Here are a few things I always keep in mind:

• You are allowed to fail expectations. It is not ‘you’ who didn’t succeed. It’s the team that failed to estimate how much time things take, what wore possible obstacles, description(s) weren’t clear, DoD (Definition of Done) wasn’t clearly defined, etc… The team learns from it, and that leads each individual to better meet expectations.
• Equally, as developers have to adapt to scrum principles, so do Product Owner(s)! This means that POs have to learn to describe what they want and need via user stories, what are epics, how to organize backlog, etc. And if they don’t know how to do that, it is my duty to teach them.

And a couple of really practical tips:

• For task estimation, play Planning poker:
  • Step 1 – Think about how much time would it take YOU to finish this task.
  • Step 2 – Everyone reveals their estimation based on step 1.
  • Step 3 – If there is a deviation in estimates, let the ones who gave the smallest and highest estimates tell how they came up with their estimate.
  • Step 4 – Back to step 1, but remember what was said in step 3.
  • Step 5 – Eventually, the team has one (the same) estimate.
• Workflow, in general, should’ve been clear to everyone, but it can be represented again quickly on a daily: where/when/what to start working on, what are the agreed practices on branches/PRs/etc., when/who does code review, how PO review works and when work get’s pushed to different main branches.
• Silent members usually get very talkative once they have a chance to talk about something they’re good at. (Let them teach/mentor another team member).