TL;DR Pointing Stories is hard and confusing 😭

After many years of being a fullstack developer, in 2016 I got my chance to build and manage a team.

My tasks and roles were clear:

  • Hire and build a team (9 people at its peak)
  • Develop the product from scratch
  • Be a Backend dev
  • Be the Scrum Master
  • Be the Product Owner
  • Be the Tech lead
  • Be the Team leader
  • Go live and don’t crash and burn

Fun fact: I failed more than once in more than one role 🙃

Some context

The team was in charge of:

  • Development (back and front)
  • Code Review
  • QA (I know this is bad, but we had no budget and it was better than no QA)
  • Deployments
  • Infrastructure design
  • 24/7 Call availability

Our Sprints durations went from 2 weeks at the start, to 3 weeks in the end (2 for dev, 1 for QA).

The Scrum Methodology was new for everyone except for one member of the team.

Meetings

Daily Standup

It took a few months for everyone to understand that they needed it to keep it short.

During my time we tested the following methods:

  • Standups around the desks
  • Standups in a conference room
  • Sit down in a conference room
  • Daily written over slack/teams

The reasons for these changes were because something was not going right and these little adjustments helped to get the team back in track.

As a Scrum Master you need to monitor and make sure people answer the basic questions:

  • What did you do yesterday?
  • What are you going to do today?
  • Any impediments/blockers? Do you need help with something?

Keep in mind that these questions might not be useful for you or your work type. Change them if you need to!.

At some point, I started using a timer on my phone and show it around to put a bit of pressure, and have fun, when someone was taking too long. Remember that Daily shouldn’t take more than 10/15 mins.

Backlog Refinement (a.k.a Grooming)

Maybe one of the most inconsistent meetings for my team.

We changed according to our needs:

  • Every day 1 hour.
  • 3 times a week / 1 hour.
  • 2 times a week / 1 hour.
  • 3 times a week / 2 hours (complex tasks).
  • The whole team was present.
  • Sometimes I decided which members were present.
  • Sometimes members decided by the team were present.

Fun fact: Sometimes it took us one whole meeting just to break down a Story or Task. 😓

The Story/tasks points (the hard part)

Front and back devs pointed all Stories/Tasks. No matter if they were front or back Stories or Tasks.

If a task was 100% back or front, the frontend or backend dev would explain it without getting into the specifics and compare it, when possible, with an old task.

One thing that happened from time to time was the team getting confused on how to point Stories.

When I had to re-explain this I used this analogy:

A Story/Task is a race that the whole team has to run, and the points (numbers) are the distance to run.

This worked for a while but after some time we had to restart and I would have to explain it over.

This confusion was because we were using numbers for the points but at the Sprint Planning Meeting we were forced to make some kind of translation between points and a fixed time length.

Let me be more clear:

Points are not a measure of time, but rather a measure of how hard the Story/Task is.

But when you plan your Sprint, you need to translate those Stories/Tasks from “How hard is it” to “how many of them can we achieve in X weeks” and that mismatch is not always easy to solve.

One thing that might be easier and that we didn’t try is to use sizes like XS, S, M, L, XL instead of numbers.

Having words instead of numbers maybe would be easier for detaching ourselves from the notion of time.

Fun fact: Sometimes I didn’t warn them on a particular Story or Task points if I thought that the team was over or underestimating it. This helped built trust and awareness in the long term 💪🏻

Sprint Planning

This meeting was done on the lasts 3 or 4 days of the ongoing Sprint and on Fridays, when we officially agreed on the final version for the incoming Sprint.

Fun fact: Unless we were pressured to deliver something important, in some Sprints I’d let the team go over/under what I believed their capacity was, without warning them just to see the results and performance. 🤔

Sprint Reviews

These meetings took place on the last day of the Sprint, on Fridays. Sometimes this meeting replaced the Daily Standup if everything was completed.

Fun fact: Sometimes the Sprint was not 100% completed! 😮

Retrospective

We only did it when it was necessary.

How to determine that?

  • If I wasn’t happy with the sprint results or if I saw problems within the team I would schedule a meeting for the first week of the new Sprint.
  • The last day of the sprint or during the first week of the new Sprint I’d ask the team if they needed a Retro and schedule one if they did.

Fun fact: We voted on who was the team member designated to take notes because we all hated writing 😂

Photo Credit: https://www.pexels.com/@fauxels