A Day in the Life of a Scrum Master in a Startup

When we think of a startup, most of us feel that it is chaotic, uncertain, involves more risk, not organized, and is difficult to manage compared to a large organization.

But in our startup, we eliminated this noise by adopting Scrum as it absolutely changes the way teams are run. In a short period, we could see that the team was developing the courage to take on challenges, the ability to focus on the goals, a commitment to achieving, respect for each other’s views, and an openness in all communications within the team.

How is a Scrum Master’s role different in a Startup?

Being a Scrum Master in a large organization is much more explicit, and the role can perform the responsibilities as outlined in the Scrum Guide. But in startups, the Scrum Master needs to perform more than these core responsibilities. Our startup wasn't staffed with roles for each function like a large organization, so I had to step in to fill the gaps.

For example, I needed to step in as the product manager to liaise with customers so we could understand their needs. I was also responsible for maintaining the inventory of our assets as well as coordinating with hiring agencies to recruit and arrange interviews, among many, many more tasks.

Simply put, the Scrum Master in a startup is a person who needs to run an extra mile compared to the role in large organizations.

But this small team size also has its advantages. In large organizations, it can be quite difficult to break through the traditional project management ideology, but in startups, the management hierarchy is lean, so it's easier to coach and motivate the team towards fully adopting Scrum.

What does the Scrum Master do daily?

Playing the role of Scrum master by the Scrum Guide was initially not possible, but I was slowly able to adapt and tried to establish a schedule that included Scrum practices.

Below is the daily schedule that I followed in our startup:

Morning

• Facilitate the 15-minute daily Scrum with the development team and product owner.
• Maintain and check the impediments backlog as per feedback from the daily scrum.

• For items which require discussion with the development team members, I hold a quick desk-side chat to see if it could be resolved.
• Review the product backlog and check if the burn down chart is updated by the development team.

Afternoon

• Meet with the product owner to clarify the product backlog items and check to see if any help is needed.
• Join the product owner to meet up with the stakeholders in case any clarification of a product backlog item is required.
• Based on availability, I arrange one-on-one meetups or a quick chat with a development team member  approximately once a week to determine how he/she is coping and if any help is needed.
• If there are any follow-ups needing to be done with the third-party vendor or customer, I call them or arrange a face-face meeting. (Again, lots of hats.)

The schedule helped me to streamline the activities of the startup and also improved the efficiency of the team. Apart from this, I also participated in Scrum ceremonies including sprint planning, backlog refinement, sprint review, and sprint retrospectives.

Below is an outline of what I have done in these ceremonies, and I highly recommend this as a guideline to adopt Scrum in a startup:

Sprint Planning

In order to maximize the value of the session, I hold a prior discussion with the product owner to check to see if the backlog has the user stories prioritized according to the value expected by the product owner. Later during the planning session, I ensure:

• the sprint goal defined by the product owner is clear to the team and the stakeholders,

• and the right amount of work is being pulled out by the development team.

The sprint planning sessions are attended by the CEO and the sales lead as they are the key stakeholders who directly capture the customer needs in startups.

Backlog Refinement

As a Scrum Master, I join the backlog refinement sessions to see that the product owner and the team can have a productive discussion, and I ensure:

• the story points estimation of the backlog items is done,
• the entire team participates and makes a collective decision,
• and acceptance criteria for the picked-up user stories are understood by the team.

Sprint Review

Prior to showcasing the increment to the customer, myself and the product owner conduct a mid-review with the internal stakeholders to check if the increment is as expected. After this, the product owner leads the sprint review session with the customers.

I make sure the discussion sticks to the agenda of the sprint and nothing beyond. Normally when we have customers, they get excited and would ask many questions and prefer to see the product features beyond the sprint. So, I politely keep reminding them that it will be taken care of in the future sprints.

Sprint Retrospective

According to the Scrum Guide, retrospectives should be conducted after every sprint. In our case, we used to do it immediately after the sprint review with the customers.

The method I use for review is DAKI. Each member is asked to identify any one thing they would like to drop, add, keep doing, and improve. We use the Trello board (sample below) to brainstorm and identify items under each category. The brainstormed ideas are then consolidated, and through common voting, specific items are identified and reviewed in the next sprint retrospective. I as the Scrum Master monitor the progress of areas of improvement and keep reminding the team.

On a quarterly basis during the retrospectives, I measure the 'happiness metric' of the team. I was inspired by this metric introduced by Jeff Sutherland in his book The Art of Doing Twice the Work in Half the Time and customized according to the startup environment.

I ask the team both qualitative and quantitative questions:

Rate on a scale of 1-5

1. How do you feel about your role right now?

2. How happy are you working with the customer?

3. How do you feel about the company as a whole?

Other questions

1. What one thing would make you happier in the next Sprint?

2. How will you contribute to raising the happiness of the team as a whole?

After consolidation, I present this to the management to show them the level of motivation in the company and what needs to be done to improve the morale and retain them.

Conclusion

I feel that being a Scrum Master in a startup is more challenging but at the same time gives more satisfaction and fulfillment with purpose. The Scrum Master should also always remember to be the servant-leader who takes a more holistic approach to work, offering service to others while promoting a sense of shared ownership and enabling collective decision making.