I am wrapping up a sprint as a volunteer scrum master with Silicon Valley Project Management, an organization that provides experiential learning through enhancing and building out a live website. The program has been a great introductory exposure to being a working SM. What follows are a few things I’ve learned and observed.

• Interleaving of backlog refinement with sprint planning

In the Scrum Guide backlog refinement and sprint planning are presented as distinct, sequential events. However, in one of my first sprints we had a backlog refinement meeting, ran out of time before completing enough backlog items, then had to carry out both refinement and planning in an interleaved manner in a later sprint planning event. It was less than ideal to mix the two different kinds of activities.

Now we are scheduling more refinement meetings and striving to better anticipate how much refinement needs to be done and to do so on more of a regular cadence. This is especially needed because of the high turnover of developers within the scrum team along with the unavoidable uncertainty and unfamiliarity with the technology we are using.

• The scrum framework does not prescribe how to do backlog refinement, how often, and who exactly is involved

In our organization the teams are experimenting with two levels of refinement. The first level is the product owner working with one or two developers who have been with the organization, know some of the backlog items, and can work with product owner to discuss and clarify them. These discussions happen first.

The second level is a more formal meeting for the entire team so that every team member is involved with this scrum event. This is also when point estimation takes place.

• Backlog refinement is a lot of work that can be ill-defined and messy

But then I read somewhere that an essential part of a backlog item is the conversation about it. It’s not just the written text that comprises an item, it’s also the dialog to clarify the text and to arrive at a shared understanding of what it means and what work is entailed.

• Backlog items – focus drift

We had an ongoing backlog item regarding an editor role for blog content. Initially the item was about both defining and using the process which the editor follows in order to edit the drafted content.

After the editing process had been applied in a couple of sprints and had settled a lot, the “weight” of the item shifted more to actually doing the editing.

So the question was, should we revise the description of the backlog item, or should we archive it and start one?

This kind of issue could arise for any kind of ongoing backlog item. In the beginning there may be some kind of startup phase where the task and how to do it is being defined and hashed out. Then the process stabilizes somewhat. Afterwards and for the indefinite future there is possible continued improvement and refinement as experience is accumulated, new things are learned, and the task evolves.

• Estimation is relative to the particular team and the particular team members

There’s a mutual dependency. Estimates are also relative to a certain point in time. As learning and experience accumulate, a team becomes more capable. As a result, estimates of effort can become smaller.

• Dependencies between backlog items within a single sprint

As a content editor, I had to coordinate with content writers on a different scrum team regarding draft and completion deadlines. We editors were dependent on them to get their backlog items sufficiently done so that we could start ours.

It’s a simple example of how the bulk of our work was loaded towards the latter part of the sprint whereas others were expected to do their work earlier. So not only were we dealing with the time limits of a single sprint, we had to carefully coordinate timing and sequencing within the sprint itself across teams.

• Focus on the sprint backlog during daily scrums

Our daily scrums have been going well, held in such a way that reminded me of someone’s suggestion that instead of the three questions that are commonly used – “what have you done, what are you planning to do, and any impediments” – keep the focus on the items in the sprint backlog, not on the developers. This helps prevent the daily scrum from devolving into a status reporting session.

• At sprint retrospectives it’s easy to come up with ideas for improvements

It’s much harder to manage those ideas, decide which ones to take on, and to follow up and have accountability. We have an ad hoc group of scrum masters and product owners grappling with this. Just how exactly do you implement the team and organizational feedback loops implied by scrum and agile approaches?

• Being a scrum master is a lot of collaborating, coordinating, and documenting

Unlike when I was a software engineer writing code, much of scrum master work consists of short tasks that can be completed in small chunks of time. There is much less of a need to have long blocks of time to focus and concentrate. Different kinds of work call for really different working conditions.

This is so relevant to all the current debates around remote vs. on-site work, expected response times to incoming communications such as Slack messages, and generally how interruptible and available one should be to colleagues.

• The scrum framework, and agility in general, emphasizes dispersed leadership, collaboration, and empowering self-organizing teams

The synergy of collective thought, judgement, and decisions can be much more effective and creative than the sum of what a collection of individuals can do. This is very much counter-cultural against the kind of command-and-control, top-down management that has been the norm since the beginning of the industrial revolution. There’s a couple of hundred years of inertia and mindset to overcome.

• Sometimes as a former software developer, I bite my tongue

As a scrum master for a team of people doing technical work on a website, I think it’s important for me not to give in to the temptation to chime in to interesting technical discussions.

My role is to pay attention to the interactions and the people and to ensure that the discussions are positive and productive and the atmosphere is conducive for people to talk freely.

• Struggling with the tools for remote collaboration

As an example, a colleague had created a Slack direct message channel with me without including anyone else. I tried to message back adding @SomeoneElse but the Slackbot said that SomeoneElse would still not be allowed access to the channel.

So it’s important to determine at the onset who should be part of a direct message conversation / channel, which Slack apparently considers to be private. It might be a good idea to set up these channels ahead of time before the conversation begins in order to make sure all the needed people are included.