If the title of this article offends you, then you're probably a Scrum/Agile purist. If it doesn't, but piques your interest, then you're likely someone who has recently started working with Scrum and are thinking, "I know the Product Backlog and even the Sprint Backlog, but I've never heard of the the Scrum Master Backlog".
The Scrum Master Backlog is a term I started using after having to explain to the teams/stakeholders I work with, my somewhat structured plan for team development. If you're a Scrum Master, then I'm sure you have this as well, you just may call it something else like… "what I do".
Currently, I define the Scrum Master Backlog as:
A series of building blocks, which Scrum teams need to become proficient in, before they can achieve success
So it's basically all the topics, disciplines, best-practice, activities, etc. I take a Scrum team through while going from Forming to Performing (thank you Mr. Tuckman).
Where to start?
As an external consultant, I've had to roll onto projects at several clients, across a handful of industries and in several countries. I needed to orient myself and begin finding solutions to the areas which could be improved as soon as possible.
When the contract is to be a Scrum Master or Agile Coach, I look for telltale signs of the most fundamental concepts/practices I expect from a Scrum team.
These include, but are not limited to, what you'd typically expect:
- Definition of Done
- Definition of Ready
- Product Backlog
- List over blockers
- Team Working Agreement
- Explicit role expectations
- …
These are examples of items on my Scrum Master Backlog.
The list is not a sequential, step-by-step list that I have to follow, but it's more like a catalog of "Greatest Hits" containing what's worked for me before and from which I can use as inspiration.
Explicit Expectations
That last one in the above list is one of my key topics I start with. It's important to express these openly and perhaps with some provocation.
For example, one of the responsibilities I place on the Product Owner (the PO), is that it is his/her role to get stories in a Ready state, so the team can bring them into the Sprint.
I also tell the development team, that they will likely need to help the PO with for example technical drawings, subtask, reasonable Accept Criteria, etc - but it's the PO's baby. The PO needs to drive any (refinement) meetings or clarifications in order to get the story Ready.
The development team's "Definition of Ready" is the gate the PO needs to get through.
On the flip side, the development team needs to ensure that when they say something is Done, that it lives up to the PO's gate - Definition of Done (DoD).
Don't purely rely on what you find on scrum.org. Use your best judgement and define the roles as you feel is needed for your specific team. Don't hold back here - dare to provoke and drive a conversation.
[As a side note, not having this one item - explicit role expectations - causes more frustration or drama than you'd imagine]
Pragmatism
Another one of my guiding beacons is doing what seems to makes sense, and then adjust as needed - but do something.
So you may object to the above section on explicit expectations. For example, if you think "The PO only represents the business and shouldn't be concerned with refinement" or maybe, "The DoD is the development team's so keep your hands off it, Mrs. PO!", then I think you're missing the point.
What's important here is that there are clear expectations between each party and we have a chance to fulfill these expectations. That there is a baseline we can start with and adjust as needed.
I'm working here to change the mindset of the people to experiment - to not let the 20% (uncertainty) get in the way of an 80% solution.
Your Scrum Master Backlog?
The items in my Backlog tend to fall into these two categories:
- Something you can take with you back to your table after the meeting to help improve: concrete tools, definitions, visuals, …
- Something to affect your mindset, attitude or approach to a problem
I'm sure you have your own backlog - even if you're not a Scrum Master. Maybe you're a team lead or department manager. But you likely have a list of important values, working habits or goals you want to achieve.
As a leader of people, I feel a responsibility to serve them the best I can. Putting these items into a somewhat structured list with some prioritization helps me stay focused and try to live up to their expectations
So what do you think? Do you have anything like this? I'd be interested in hearing your thoughts.
Smiles - Jim Morris
P.S. There are other indicators I look for when assessing a Scrum team: number of stories in the backlog, number of stories in the Sprint, size of team, the general attitude or "feeling" in the room, so it's just not the Scrum Master Backlog.
P.P.S. Obviously, I respect the Scrum Guide and the work done by the guys at the ski resort, but I also remember that it's a framework and try not to get too bogged-down in the drama of exactly what Scrum or Agile is. I focus on the intention or spirit and try to get into the best mindset.