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.

image

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.
SNAGHTMLbdbd026 

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. 

SNAGHTMLbc9b090

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.

SNAGHTMLbcccca5

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.

Comments (3)

  1. Rui Melo says:

    It is an impressive process to watch. Specially in teams that have never worked together before. From the outside you could say it is very similar to an F1 race, with competitors finding their place in the race. But that’s where the comparison stops:
    * The goal is to get everyone to the finish line and in the first place.
    * The players in this race are volunteers, and they decide if an idea is good enough to invest effort on. There is a presentation to the whole community, pitching the concept and the goal. The community then registers the interest in participating. Low participation means the idea is not interesting, hence the project will not take off.
    * The Project Lead is also a volunteer and drives the initiative from that moment on.
    * The PO is a member of the team
    * Every lap (aka sprint) the team takes a snapshot of the initiative and decide on adjustments

    I guess the hierarchic management can be represented by the phrase “Need help? Shout!! Otherwise, go do your thing and have fun :)”

  2. Khanh Nguyen says:

    This article doesn’t tell a whole lots of things. It’s too general…

    1. Khanh, we are intentionally not going into much detail and duplicating content we reference. The Managing Agile Open-Source Software Projects with Microsoft Visual Studio eBook goes into a lot of detail around how we manage ideas, our backlogs, and associated releases. What would you like us to cover in more detail?

Skip to main content