How I Started the Scrum Team without Stressing about the Scrum Terms – From Doubt to Belief

Returning to the time I was told by my team manager I was going to form a new team to work on a new product, I’ve never thought that in almost 4 years, my team has grown and sustained in a way different than other teams in the company.

When I was in my previous team, many people struggled using Scrum. People are obsessed with Story Pointing. Some team members refused to attend the Sprint Review and Retrospective. Everyone works without a clear goal but only emptying the backlog and fighting the deadlines. Arguments like Code Refactoring versus meeting the deadlines and estimation versus actual were everywhere. There were times that I doubted if Scrum brought us a tough time. There were times that I almost wanted to quit the job due to the burnout.

“You can do anything that would be the best way.” said my team manager.

Starting a team could be a nightmare, but it is also a chance to reveal my knowledge in running a team with the knowledge I gain. If my team could sustain for years, I’ve uncovered a better way of working with Scrum. Otherwise, I would stew in my own juice.

I accepted the challenge and started my long-life experiment.

My team manager and I agreed that a frequent feedback loop is essential since stakeholders want to learn more about the progress. This leads us to decide to run in a 1-week sprint. Frequent feedback helped us clear the misunderstanding to the business earlier, especially for a newborn product team. We could change the direction if we realised something went wrong. I didn’t tell the team we would run in 1-week sprint. Instead, I said we would review the progress of our product every week.

As a Product Owner, one of my tasks was to prepare a weekly update to the product. The expected reader is the CIO. I quickly realised the rule – never keep the weekly update unchanged. How could this be done? Simple, WIP limit comes into play. But instead of explaining the complex mathematics to the team, I invented a phase – “weekly-driven development.”

“Each week, we must move something to the ‘Done’ column in our weekly update,” I said to the team, “What is the single smallest possible thing we could do to improve the product or satisfy the users? We invest all our effort into it and ignore the rest.”

That’s how we began to discuss our Sprint Goals.

There were 3 developers in the team, including me, during the early stage. As the technologies were new, the business was new, and the developers were inexperienced, our capacity was tiny. All the PBIs were like aliens to us. We couldn’t determine the complexity of the PBI before we actually worked on it.

“Every Product Backlog Item looks like a spike to us,” I replied when someone mentioned the Story Pointing, “How can we decide the Story Point?”

I then set the Story Point to 3 for all the PBIs according to the tradition of my previous team. Later on, I omitted the Story Points at all.

As a result, I scheduled the Sprint Planning on Monday, at the same time as the Daily Scrum. This event, as of today, is time-boxed for 15 minutes only. It is held to reconfirm our Sprint Goal and align how we start working for the upcoming 2 days. We accept that our initial plans are limited by the fog beforehand and expect it will change over time. Later on, I realised my idea was similar to Maarten Dalmijn’s Hummingbird-style Scrum mentioned in 2021. Say goodbye to 4-hour Sprint Plannings full of Story Point debating.

It’s still a controversial topic on giving Story Pointing in my company. Not until I deep-dived into Kanban and Flow Metrics last year could I explain to my colleagues from other teams about abandoning Story Pointing. I also wrote a few blog posts on Flow Metrics and Story Pointing.

“If someone forced us to set Story Point to the PBIs, I’d set all of them into 2, and shut them up.” said one of our developers recently.

Previously, I was unsure if Scrum worked in my newborn team. I did many experiments and avoided spamming people with Scrum (and Agile) terminologies. It is one way to pop the Scrum bubbles. Stakeholders and managers don’t necessarily pay attention to the Scrum. It isn’t the job requirement for the developers to revise the Scrum Guide. Turn everything into goal-driven work. The team will eventually shape the work process into a form similar to Scrum.

Later on, I will write about product backlog management and the other Scrum events.