Subscribe to News

    Popular Stories

    7+1 Principles And Five Frameworks for Agile Portfolio Prioritization
    Weave Toolkit: SAFe PI Planning with Weave
    Giving Thanks for Portfolio Management
    Agile 2015 Keynote: Awesome Superproblems
    Agile Portfolio Management: Five Core Frameworks for Product Portfolios
    Written by Luke Hohmann
    on November 11, 2016

    The central tool of managing work in Scrum/Agile teams is the backlog, "an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product." (ref)

    And that's mostly true. But it doesn't reflect the reality of Agile, especially for Product Managers with an entrepreneurial spirit (hmmm... all of us). The reality of Agile is that there are three "logs" - the Backlog, the BLACKlog and the Dreamlog. In this post I'll share which of these are normal, which are healthy and which are dangerous and how to fix them.

    Let's start with your backlog, since that's the one log we all have!


    The Backlog

    I take the definition of the Product Backlog provided by Scrum at face value, because it is a good one. The Scrum Guide is quite explicit about the many ways in which Product Owners collaborate with the Scrum Teams and other stakeholders in managing the backlog. Simply put, smart Product Managers know they need help in managing the backlog.

    Unfortunately, not enough Scrum practitioners follow my lead. They follow simplistic, and incorrect, views of a Scrum-centric Product Manager who is solely managing the backlog. In this model, the all-knowing and all-powerful PM not only sets the vision of the product, they define and prioritize all of the backlog.

    HA! Good luck with that.


    My own experience is far more congruent with the Scrum Guide: As the CEO of a growing B2B software company, I nominally play the role of the Product Manager for our suite of collaboration tools. I say nominally, because I get a lot of help in managing our backlog: Our dev team is remarkably gifted at taking the barest hints of an idea—even before it becomes a user story— and finding a way to deliver something awesome. Our sales and services teams are fearless in advocating for changes that address customer issues even before our customers identify a problem. Design Jam 3
     Conteneo Design Jam

    And best of all? Our customers help us improve our products and services through design jams, joining us for Sprint reviews, trying out ideas in our preview system and sending us loads of feedback.

    And you know you're customers and partners are Agile when they send you feedback as a user story. Here is one just today from Certified Conteneo Collaboration Instructor Raphael Goumot:

    Hey Luke, could you add this to your backlog?

    As a facilitator of a Conteneo forum,
    I want to drive every participant to the same zone (forced zooming)
    in order to focus conversation and align the participants.

    Yes, we added that one to our backlog!

    So, if we have a Backlog, what's a Dreamlog? And do you need one?

    The Dreamlog

    Our Dreamlog is our repository of our hopes and dreams for our product. It is, admittedly, a bit of a tangled mash of "stuff" drawn from:


    Dreamcatchers are handy for Dreamlogs

    Our beliefs
    We believe that collaborating teams are the world's best hope for solving the problems we face.

    "Crazy" Customer Feedback: Hey Luke, we've got the results of more than 3500 Prune the Product Tree's in your system - can you sift through every Apple and surface the best ideas?

    Our own wild ideasLet's capture every move participants make in the event stream so that one day we can build psychological profiles of participants and identify who is best at solving certain kinds of problems.

     Innovation Games® are Dreamcatchers for Innovators!



    Our philanthropic ambitions: How can we make sure our server grid can scale to support the millions of simultaneous forums we're planning at Every Voice Engaged Foundation-a topic we'll explore at Engage the Bay, our upcoming conference on civic engagement, Dec 8/9 at NetApp in Sunnyvale, CA. 

    Cool and crazy things we seeDid you see that awesome data visualization from the team at Tableau?

    Our Dreamlog inspires us to "keep going when the going is tough", challenges us to think about the world in different ways, opens our eyes to the awesome new ideas from other companies (including competitors!) and keeps us searching for the deepest understanding about our customers truly unmet needs and how to solve them.

    I'm willing to bet that you have a Dreamlog too. Good! Dreamlogs are natural, healthy, wonderful things. And if you have one, you should share it: talk about it, build on it, nurture it and let it nurture you.

    I'll go even further: We created Conteneo because we're committed to making the world a better place. We didn't create Conteneo because we had, or wanted to get, VC funding. And we didn't create Conteneo so that we could flip it. I'm not saying that striving to get VC funding or building a company to flip is bad. If that's your cup of tea, by all means drink it. I just don't know of many (any) sustainable, truly remarkable organizations who focus more on getting funding or flipping than on solving important customer problems. Put another way, we like to talk more about our customers and actual revenue instead of the amount of our funding, which makes Conteneo a bit of an anomaly in Silicon Valley and helps explain why we keep growing when some of our competitors have run out of funding and have therefore stopped improving their products.

    And if you don't have a Dreamlog? Oh my. That's a tough one. I don't think I could work on any product that didn't have a Dreamlog. It would be dead, lifeless, uninspiring. If you really don't have a Dreamlog for your product I feel a bit sad for you and strongly recommend that you find a product with a Dreamlog that inspires you to realize the best parts of yourself in service of others.

    As for our Dreamlog, more of it will be coming true soon with the forthcoming release of an entirely rewritten platform - Conteneo Weave.

    The BLACKlog

    I define the Blacklog as

    the work that Scrum teams do that is purposefully hidden from management because management doesn't care, doesn't support, doesn't agree with, or otherwise doesn't want to understand or acknowledge.

    Blacklogs are a sign of a dysfunctional organization - one that may or may not be trying to practice an Agile method, and certainly one that does not embrace the values of Agile, Scrum, Lean Kanban, or whatever other major Agile method the organization has chosen.

    I see blacklogs all of the time, especially in organizations that are struggling with some aspect of their Agile transformation. Here are three of the most common blacklogs I see:

    Technical blacklogs: These are blacklogs for technical work that a team must do that the PM chooses to ignore. For example, deploying code into production, upgrading libraries, or addressing a security vulnerability are all legitimate work and should be put on the backlog.

    Investigative blacklogs: PMs like me are an incredibly demanding, often curiously demanding bunch of people. We'll see something, recast it for our own products, and then ask our team to build it - often forgetting that our teams need time to investigate and learn new technologies. Simply put, when my team asks for an investigative story, I always say yes (though we do negotiate the priority ;-).

    Iteration blacklogs: The mad rush of the world to churn out features has converted Agile from its roots of Iterative-Incremental development to pure incrementalism. That's a huge mistake. Teams need the opportunity to iterate on things they've accomplished - even when the software is working just "fine".

    I find that there are two common root causes to blacklogs.

    Lack of Collaboration between business leaders (PMs and related stakeholders) and development/production/operations teams.

    Rejection of Reality that sometimes things take longer than we want, that new features have to be delayed to address a security vulnerability, or that developers need time to learn.


    The simplest way to get rid of blacklogs is to insist that all work - 100% - every single bit of work - that the dev team undertakes is represented on the Backlog. This ensures that you're arguing (collaborating ;-) about the full set of work that needs to be undertaken by the team to produce the Whole Product. And we have a whole boatload of collaborative frameworks to help you do exactly that!

    This is a tough ideal, and candidly, I know that sometimes even I fall short of this goal (like when I asked our designer to help fix an image for a newsletter - he just did it - but I really should have put it on the backlog). Fortunately, our team has a high degree of trust and discipline (normally, one of us would have put it on the backlog and then prioritized it accordingly in a transparent way).

    What's your Dreamlog?  


    Let us know what you think. 

    Add your comment below.

    You may also like:

    Agile Scrum PI Planning scaled agile framework SAFe product management

    Weave Toolkit: SAFe PI Planning with Weave

    A challenge faced by many SAFe organizations is creating an efficient PI planning process: one in which the in-person me...


    How to Run HUGE Retrospectives Across Dozens of Teams in Multiple Time Zones!

    Few years ago, Luke Hohmann, Conteneo's CEO, was helping with a large scale enterprise Agile Transformation project lead...

    Agile Innovation Strategy safety diversity and inclusion

    Anonymous Participation: Collaborating Safely on Sensitive Topics

    We have released fully anonymous participation for  organizations that need to increase safety when tackling sensitive t...