The secret sauce to managing our backlog and TODO lists

We continue with our how has the Ranger community evolved … series, by chatting about our experiences of managing backlogs and to-do lists. If you’re looking for in-depth technical information on the tools we use, you can explore Visual Studio Team Services Agile Tools.

Where we came from and where we’re heading

We started using the Microsoft Solutions Framework (MSF), which defined principles, mindsets, governance, checkpoints and an iterative approach to solution development. At the time we needed a formal process to establish ourselves and MSF was suited to our 6-12 month roadmaps. Early 2007 we started to experiment with Scrum, by applying the framework to a project that was completely off-track. In one of the daily scrums we realised that not only was the project back on-track, but the team was energised and collaborating as one. It was that moment of insight, that inspired us to us share our experience and food for thought in the fun and easy to read .NET Enterprise Solutions … Software Engineers on their way to Pluto (aka.ms/wsbook3) book.

Over the years we adapted Scrum to our part-time, volunteer-based, and geographically distributed teams, defining a framework that we referred to as “Ruck”, also known as a Maul or “loose scrum” in the game of Rugby. It lead to another book, Managing Agile Open-Source Software Projects with Microsoft Visual Studio Online (aka.ms/wsbook4), in which we shared our learnings of embracing Visual Studio Team Services, Scrum and Kanban to manage our projects from a team to a portfolio level. As you’ll notice, continuous learning and sharing our experiences is a critical link in our DNA.

2015 was one of the pivotal times for the Ranger program. We switched from a rigid, well-defined and common framework, to flexible, self-managed and self-organised teams.

Our backlog(s)

There was a definite period of chaos and disorder, as we went through the process of coordinating self-organised, self-managed, and autonomous teams working together in their own way. Asking these teams for their secret sauce, is like asking them for their favourite Ketchup sauce … it varies. The order that emerged is based on the following illustration, which we loaned from our Open-Source Software Projects with Microsoft Visual Studio Online book.
 

We create one Epic [1] for each product. It defines the minimal viable product, the sponsor, the WHAT, WHEN, and WHY. It’s owned and tracked on a program level. We create one to three [2] Features [3] per Epic, which define the features we are planning to implement the release. We collaborate on the Features at a program and team level [4], the product owner continues to be the sole person responsible for managing the Epics and Features on the Product Backlog, but the remaining backlog is owned and tracked by the team. This is where the commonality on a program level ends.

Some teams break down the Features into Product Backlog Items  (PBI) [5] and some break these down further into Tasks [6]. Most of the teams have embraced the Kanban Board as their preferred place to collaborate and monitor their project and it’s progress. It even allows team members to capture child work items on the board, as shown below, which introduces simple and an effective way  for team members to maintain a TODO list for each Feature and PBI. 

The visualization offered by the Kanban board allows us to identify bottlenecks, growing and idling queues. Most importantly it enables us to continuously improve the team’s process, reduce waste, and visually observe the impact of change.

But what’s the secret sauce?

I believe it’s the trust we place in each other!

As a Program Manager I trust that the team will self-organise and effectively self-manage their team environment, their process, and their backlogs of Features, PBIs and Tasks. In turn the team trusts the Program Manager and Product Owner to organise and manage the portfolio, defined by the backlog of Epics, guiding and keeping the team informed of business strategy changes that may impact the product. Similar to a Scrum Master, the Program Manager role has evolved into a servant-leader and enabler for the team.

Lastly, keeping it simple allows us to create a level of order and consistency, ensuring that everyone can keep focused on what’s really important … delivering value to our users.