Dear Scrum Master, do you wish that you could affect continuous improvement, but with buy-in?
Frontlog is a practice that manages process experiments like a backlog, facilitating conscious evolution by your team.
It ain’t a novel idea, but after a decade of Agile Coaching, I’ve been told it’s a very helpful one, so consider this my gift to you. Happy perpetual Holiday-of-your-choice.
like a backlog, but for Scrum Masters
How It Works
Setup: It starts with an empty one-dimensional, ordered list, which you might otherwise consider an empty backlog.
Input: The Scrum Master thinks up two-to-five items of kaizen, or actionable items of continuous improvement, for their team. These can come from observations, retrospectives, team conversations, or external influence.
Action: Refine and prioritize these items, now Frontlog items, with the whole team, as if they were refining and prioritizing Product Backlog items. This includes ensuring there is acceptance criteria, and discussing other “entry criteria” found in a Definition of Ready. (This similarity in treatment reflects an analogous relationship: if Backlog items can be considered product experiments, then Frontlog items can be considered process experiments.)
Output: This populated Frontlog facilitates sustainable adaptation, hopefully leading to conscious evolution by the team, specifically via taking the already familiar discipline of Scrum practices for product development, and reapplying them to process improvement.
Iteration: Much as a Sprint Backlog is generated from a Product Backlog once a Sprint, Frontlogs can be treated similarly. And much as the Product Backlog changes mid-Sprint, the Frontlog can take on new or refined ideas in an ad hoc manner, or after the Sprint Retrospective, or after conversations with fellow Scrum Masters upon reviewing each other’s Frontlogs.
like a backlog, but for Scrum Masters
How It Works Better
In lieu of a Definition of Ready specific to Frontlog items, I think about Frontlog items as having three levels of quality.
The first is when the FLI is just the articulation of the process experiment: the ‘What’.
The second is when a ‘Why’ is added, much as the User Story Form has that ‘benefit’ component. This outcome is what really matters, and what should act as the motivation to try something to achieve it. This something is the FLI, which means that if it doesn’t work, another FLI can be tried towards the same end.
The third level of quality is when a quantitative and time-bound component is added, similar to adding Key Results to the Objective that is the ‘Why’, pulling from the OKR framework. Having a time-bound goal for a metric (or metrics!) can provide healthy constraints for the experimentation, a measure of progress, and a means to declare if the team has evolved favorably.
like a backlog, but for Scrum Masters