The secret sauce to managing our backlog and TODO lists

The page describes how the Ranger community’s approach to backlog management changed over time. It began with Microsoft Solutions Framework for formal 6–12 month roadmaps, then experimented with Scrum on a troubled project and found that daily scrums helped restore coordination while energising the team. Over the years, the group adapted Scrum for part-time, volunteer-based, geographically distributed teams through a framework they called Ruck, and later moved in 2015 from a common, rigid framework to flexible, self-managed and self-organised teams.

The backlog model that emerged uses one Epic per product to define the minimum viable product, sponsor, and the what, when, and why at program level. Each Epic is split into one to three Features for a release, with the product owner remaining responsible for Epics and Features on the product backlog, while teams own the rest of the backlog. Teams then handle Features in their own way, often breaking them into PBIs and sometimes Tasks, with many using the Kanban board to collaborate, track progress, capture child work items, and maintain TODO lists. The page argues that the main factor behind this working model is trust between program leadership and teams, together with keeping the system simple so attention stays on delivering value to users.

Fichamento

#

• The Ranger community presents backlog and to-do list management as part of a broader series on how the community evolved.
• The group originally used Microsoft Solutions Framework because it provided principles, governance, checkpoints, and an iterative process suited to longer roadmaps.
• In early 2007, they tried Scrum on a project that had gone off-track and found during daily scrums that the project recovered and the team became more unified and energised.
• They later shared those experiences in a book about software engineers on their way to Pluto.
• Scrum was adapted for part-time volunteers working across different locations through a framework they called Ruck, described as a loose scrum inspired by rugby.
• Another book was used to share what they learned from combining Visual Studio Team Services, Scrum, and Kanban to manage projects from team to portfolio level.
• The text says that continuous learning and sharing experience is a central part of the group’s culture.
• In 2015, the Ranger program shifted from a rigid shared framework to teams that were flexible, self-managed, and self-organised.
• That transition brought a period of disorder while autonomous teams coordinated in different ways.
• The page says there is no single team recipe for managing backlogs because each team’s approach differs.
• Their shared structure starts with one Epic for each product.
• An Epic defines the minimum viable product, the sponsor, and the what, when, and why, and it is owned and tracked at program level.
• Each Epic is broken into one to three Features that define what is planned for the release.
• Features are handled collaboratively at both program and team level.
• The product owner remains solely responsible for Epics and Features on the product backlog.
• Everything below that level in the backlog is owned and tracked by the team.
• Teams diverge after Features: some create PBIs, and some break work down further into Tasks.
• Most teams use the Kanban board as the main place to collaborate and observe project progress.
• The board also lets team members add child work items directly there, which supports simple TODO lists for each Feature and PBI.
• The Kanban visualisation helps identify bottlenecks as well as queues that are growing or idle.
• The text says this visibility supports continuous process improvement, waste reduction, and observing the effect of changes.
• The stated secret behind the model is trust.
• The Program Manager trusts teams to self-organise and manage their environment, process, and backlogs of Features, PBIs, and Tasks.
• In return, teams trust the Program Manager and Product Owner to manage the portfolio through the backlog of Epics and to keep them informed about business strategy changes affecting the product.
• The Program Manager role is described as having evolved into a servant-leader and enabler role similar to a Scrum Master.
• The page closes by saying that simplicity creates enough order and consistency to keep everyone focused on delivering value to users.