Chris Gagné

Delight customers. Create value. Do good.

Building the Right Product

I shot an interview with Adolfo Foronda about building the right product as a product owner. Check it out! Click “Continue reading” below for my speaking notes, which are an approximate transcript.

Continue reading

On Not Saying No

I shot an interview with Adolfo Foronda about saying “no” as a product owner. Check it out! Click “Continue reading” below for an approximate transcript.

Continue reading

Healthy Team Backlogs

Originally published on the eBay Tech Blog.

What is a backlog?

Agile product owners use a backlog to organize and communicate the requirements for a team’s work. Product backlogs are deceptively simple, which can sometimes make them challenging to adopt for product owners who may be used to working with lengthy PRDs (“project requirement documents” or similar).

Scrum most commonly uses the term product backlog. However, many product owners who are new to Scrum are confused by this term. Reasonable questions arise: Does this suggest that a team working on multiple products would have multiple backlogs? If so, how do we prioritize between them? Where do bugs get recorded? What happens if work needs to be done, but it isn’t associated with a product; do we create a placeholder?

Therefore, we prefer the term team backlog. Our working definition of team backlog is “the maintained, ordered list of work that the team plans to do now or in the future.” This is a dense description, so let’s unpack it a little.

“The” and “Team”

  • We say the and team because each team needs a single source of truth to track their current and future work.
  • If a team is working on multiple projects or products, all of the work for those stories should appear on a single, unified, team backlog.
  • Teams do not generally share backlogs.


  • Work includes almost everything that the development team needs to do.
  • Features, bugs, technical debt, research, improvements, and even user experience work all appear on the same backlog.
  • Generally speaking, recurring team meetings and similar events do not appear on the backlog.


  • We say maintained because the backlog is a “living” artifact.
  • The product owner and team must continually update and refine their backlog. Otherwise, the team will waste time doing useless work and chasing requirements.
  • This requires several hours per week for the product owner and 1–2 hours per week for the team. It involves adding, ordering, discussing, describing, justifying, deleting, and splitting work.


  • We say ordered list rather than prioritized list because the backlog is ordered, not just prioritized.
  • If the backlog is only prioritized, there can be multiple items that are all “very high priority.”
  • If the backlog is ordered, we communicate exactly in what order those “very high priority” tasks should be worked on.

“Plans to Do”

  • We say plans to do because we regularly delete everything from the backlog that we no longer plan to work on.
  • Deleting unnecessary work is essential. Unnecessary work clutters up our backlog and distracts from the actual work.

What makes a backlog healthy?

Now that we know what a backlog is, what makes a backlog healthy or not? While what makes for a good backlog is somewhat subjective — in the same way that what makes a good PRD could be subjective — there are 10 characteristics that we’ve found to be particularly important.

Would you like to know if your backlog is healthy? Download this handy PDF checklist, print it out, then open up your backlog and follow along. For each criterion, take note of whether your backlog currently does, doesn’t, or only somewhat meets the criterion. In exchange for less than half an hour of your time, you’ll have good sense as to the health of your backlog and a few ideas for improvement.

  1. Focused, ordered by priority, and the team follows the order diligently

    • At all times, anyone can look at the backlog and know what needs to be worked on next without ambiguity.
    • Even if you have several “P1” issues, the team needs to know which P1 issue needs to be addressed next. Simply saying “they’re all important” will paralyze the team.
    • Although the PO is responsible for the product backlog order and makes the final call, the PO should be willing to negotiate the order with their team. The team often has good insights that can mitigate dependencies or help the PO deliver more value.
    • Stay focused on one thing at a time when possible to deliver value earlier and reduce context switching waste.

  3. Higher-value items towards the top, lower-value items towards the bottom

    • In general, do high-value, low-cost work first (“lowest hanging fruit”).
    • Next, do high-value, high-cost work because it is usually more strategic.
    • Then, do low-value, low-cost work.
    • Finally, eliminate low-value, high-cost work. You will almost always find something better to do with your time and resources, so don’t waste your time tracking it. It will be obvious if and when that work becomes valuable.
    • Hint: You can use Weighted Shortest Job First or a similar technique if you’re having difficulty prioritizing.

  5. Granular, ready-to-work items towards the top, loosely-defined epics towards the bottom

    • Items that are at the top of the backlog will be worked on next, so we want to ensure that they are the right size to work on.
    • The typical team’s Definition of Ready recommends that items take ≤ ½ of a sprint to complete.
    • Delay decision-making and commitments — manifested as small, detailed, team-ready items — until the last responsible moment.
    • There is little value specifying work in detail if you will not work on it soon. Due to learning and changing customer/company/competitive conditions, your requirements may change or you may cancel the work altogether.

    What is an Epic?

    • An “epic” is simply a user story that is too large to complete in one sprint. It gets prioritized in the backlog like every other item.
    • JIRA Tip: “Epics” in JIRA do not appear in the backlog for Scrum boards. As a result, they behave more like organizing themes than epics. Therefore, we suggest using JIRA’s epic functionality to indicate themes and user stories with the prefix “Epic: ”  to indicate actual epics.

  7. Solutions towards the top, statements of need towards the bottom

    • Teams can decide to start working on an item as soon as they know what customer needs they hope to solve. However, collaborating between product, design, development, and stakeholders to translate customer needs into solutions takes time.
    • As with other commitments, defer solutioning decisions until the last responsible moment:
      • Your ideal solution may change through learning or changing conditions such as customer, competitors, company, or even technology options.
      • You may decide not to work on the problem after all.

  9. 1½ to 2 sprints worth of work that’s obviously ready to work on at the top

    • Teams sometimes surprise the product owner by having more capacity by expected.
    • Having enough ready stories ensures that the team is:
      • Unlikely to run out of work to pull into their sprint backlog during sprint planning.
      • Able to pull in additional work during the sprint if they complete the rest of the work on their sprint backlog.
    • It should be obvious what work is and isn’t ready to work on so that the team doesn’t have to waste time figuring it out each time they look at the backlog.
      • Some teams prefix a story title with a “* ” to indicate a ready story (or a story that isn’t ready).

  11. The value of each piece of work is clearly articulated

    • Your team should be able to understand why the work is important to work on.
    • There are three primary sources of value (and you can define your own):
      • User/Business Value: Increase revenue, reduce costs, make users happy
      • Time Criticality: Must it happen soon due to competition, risk, etc.?
      • Opportunity Enablement/Risk Reduction/Learning: Is it strategic? Is it necessary to enable another valuable item (for example, a dependency)?
    • You won’t usually need a complex financial projection, just a reasonable justification as to why the item should be worked on next relative to all other known possibilities. Time previously spent with complex projections can instead be used to talk to customers and identify other opportunities.

  13. The customer persona for the work is clearly articulated

    • The “As a” part of the “As a ____, I can ___, so that ____” user story isn’t a mere formality; it’s an essential part of user-centered product development.
    • Who is the customer? Who are you completing this work for? Even if you’re on a “back-end” team, keep the end-user in mind.
    • Partner with your designer to identify your personas and reference them whenever possible. Is this feature for “Serious Seller Sally?” Can you imagine her personality and needs just as well as any of your friends?
      • Example: “As Serious Seller Sally, I can list items using a ‘advanced’ flow so that I can get the options I need without the guidance for casual-sellers that only slows me down.”
    • Tool Tip: Most teams and POs find it best to put just the “I can” part the user story (for example, “List items using a ‘advanced’ flow”) in the planning tool’s title field. Otherwise it can be harder to read the backlog. Put the entire user story at the top of your tool’s description field.

  15. ≤ 100 items (a rule of thumb), and contains no work that — realistically — will never be done

    • This is a general rule. If your team works on many very small items or has considerable work that you must track, your backlog could be longer.
    • Assuming that each backlog item takes a minute to read and understand, 100 items alone would take over an hour and a half to process. Keeping our backlog limited like this makes it easier and faster to fully understand.
    • A longer backlog is more likely to contain features that will never be built or bugs that will never be fixed. Keeping a short backlog helps us ensure that we triage effectively and delete items that we are unlikely to work on.

  17. The team backlog is not a commitment

    • A Scrum team cannot make a realistic, firm commitment on an entire team backlog because:
      • It has not been through high-level design (for example, tasking at end of Sprint planning).
      • The risk of missed dependencies and unexpected requests/impediments is too great.
      • “Locking in” a plan that far into the future considerably restricts flexibility
    • A Scrum team can make a valid commitment on a sprint backlog if there are no mid-sprint scope changes and few unexpected requests and impediments.

  19. Backlog reflects the release plan if available

    • If the team has conducted release planning, create pro forma sprints with items in your planning tool to reflect the release plan.
    • If there are production release, moratorium, or similar dates, communicate those too.
    • Update the release plan at end of each sprint as you learn.

A Free, 30-Minute Guided Metta (Loving Kindness) Meditation

Metta is a Pali word that means “loving kindness.” A metta meditation is a practice of directing loving kindness towards others and oneself. Here is a free, 30-minute guided metta meditation that I’ve recorded so that I can share it with you. Please feel free to share it with anyone else that you’d like.

This is based almost verbatim on the metta practice described in Upasaka Culadasa’s book, “The Mind Illuminated.” I have recorded this with his permission so that I may offer it freely to everyone.

I hope you find it of great benefit to you. This is my first time recording a guided meditation, so I hope you’ll share your feedback and ideas with me! I recorded it on a MacBook Pro using GarageBand and a Shure VP83 LensHopper microphone mounted to a table-top tripod several inches from my mouth. The ending bell and ambient forest background sounds are both public domain, courtesy of the fine folks at

I decided to use a bit of a very quiet nature track in the background to replicate what this might sound like if I had recorded it at a place like Cochise Stronghold Retreat rather than my apartment in San Francisco. Otherwise the absolute silence interspersed with my voice every minute or two might have been too jarring. Please comment and let me know if I should turn the background sound up, down, or eliminate it entirely.

MindTime: a way of looking at human behavior through the lens of time

My dear friends John Furey and Vincent Fortunato have been working on a project called MindTime for many years. I first learned about it several years ago and it’s become a dominant—and very useful—lens through which I’ve come to understand myself, friends, concepts, and communities.

It is, at its simplest, a highly-predictive personality profile. At its broadest, it’s a tremendous lens through which to understand human behavior.

Unlike the MTBI and similar profiles which uses culture-specific linear axes (e.g., extroversion and introversion don’t mean as much in East Asia), MindTime focuses on people’s universal relationship with time.

If I were to say that people are varying degrees of past-, present-, and future-thinking, I imagine this would already make intuitive sense to you. Further, this can be applied to any word, idea, company, community, brand, and even country.

Here are some examples:

  • Coca-Cola is a “past” brand and Pepsi is a “future” brand
  • Hope is a “future” word, tradition is a “past” word
  • Republicans are generally past-thinking (“Make America Great Again” implies that the past was better) versus Democrats are generally more future-thinking (Obama’s “Hope” is the idea that things will be better in the future).
    • As an aside, I think Clinton’s “Better Together” was too present-thinking to appeal to future-thinking millennials.

If a heavily future-thinking person finds themselves in a heavily past-thinking company or team, there may be a lot of conflict. Same goes for relationships (from personal experience). Simply understanding where everyone is coming from can improve empathy, happiness, and performance. My friend has used this to help develop teams at a variety of companies.

If you’re intrigued, check out their site or try the profile (free, no registration, takes about 2 minutes). I’d love to hear your thoughts, especially whether or not you find the results both specific and accurate.

For you past-thinking dominant types, you’ll be delighted to know that there’s very solid science behind it.

Agile Lessons from the NUMMI Team Member Handbook

I recently came across Mark Graban‘s “Highlights from the Original 1984 NUMMI Team Member Handbook” series. Digging through the archives at Ephlin’s UAW office papers were archived at the Walter P. Reuther Library at Wayne State University in Detroit, Mark found some absolutely extraordinary gems, including this one.

Standing on the shoulders of giants, I reached out to the archivists at the library to see if I could get a copy of the full handbook. They cheerfully obliged, and rather quickly at that!

Grab the PDF and peruse for yourself. The first several pages are the most interesting, but even as you explore the rest of it pay attention to how human and reasonable it is. Mark provides an excellent commentary on several key sections, so I’ll try to avoid highlighting the same thoughts. I hope you’ll share your own findings and commentary in the comments below.

Here are some of the gems I’ve found:

Notice that the first objective is “To help [employees] develop to [their] full potential.” In fact, these objectives start with the individual employee, progress to the company, and then ultimately end with the customer receiving the “highest quality automobiles in the world.” This is a notable inversion from the usual objectives, which usually prioritize stakeholders and customers, then the company, then—if at all—the individual employee.

This is extraordinary in two ways. First, employees are given the expectation that they are going to have a greater autonomy and influence over how other aspects of the organization operate. I’ve heard the statistic that Toyota’s 300,000 global employees make a total of one million suggestions annually, 97% of which are implemented. Secondly, note that the employee handbook is characterized as helping the employee “do [their] job better,” a far cry from the usual purpose of this kind of handbook (protecting the company’s interest).

This sure sounds a lot like a gemba walk to me…

Product Owners: are you making the mistake of telling your team how to do something rather than just what you’d like done? Are you open to product ideas from all sources?

Managers: If an employee comes to you with a suggestion, are you willing to help them turn it into an experiment and examine the results together, or will you argue with them based only on your conjectures?

This is fundamental. Modern software development—particularly at large —corporations—is complex, not complicated. Therefore there is always uncertainty. There will always be things that we do not know. If we cannot create the safety for individuals and teams to acknowledge this, they may not come to learn.

This also reminds me of Mary Poppendieck’s comment in her talk, “The Tyranny of the Plan (transcript):”

Basic project management measurement is variance from plan. So say you vary from plan. What happens? Oh, you’ve got a performance failure, right? Maybe. There is another way to look at performance from schedule. Perhaps it’s not the person who’s trying to manage the schedules fault. Perhaps it’s the schedule’s fault instead. In fact, if the schedule is a hypothesis rolled up from a lot of detail, it’s the schedule’s fault, not the person’s fault and what we really should do is view it as a learning opportunity.

Guess what? We’ve learned something about our capability to schedule and we have to rethink how we’re going to schedule because this particular one wasn’t correct. We came up with a wrong hypothesis. What is it about our scheduling approach that gives us wrong hypotheses?

In this case, it is the manager that accepts the knee-jerk explanation that a human being is to blame, punishes them, and concludes their inquiry. They wholly miss the opportunity to learn.

This reminds me a little bit of the first line of the Agile Manifesto: “Individuals and interactions over processes and tools.” It also reminds me of my fellow coach Monica Yap reminding me to think of how to make things effective (total systemic, long-term efficiency) rather than merely efficient (local and short-term). 

I truly believe that Toyota cared a great deal about each individual’s safety and the ramifications for the individual and their family. This is a far cry from GM’s culture at the same plant just a few years before: “You just don’t see the line stop. I saw a guy fall in the pit, and they didn’t stop the line.

At first it doesn’t seem like software companies could have a problem with safety. After all, there are many physical hazards in a factory that don’t exist in an office environment.

However, we see safety violations all the time if we broaden the term to include any event that could harm the employee, compromise performance, and embarrass the company. Surely the recent allegations of sexual harassment at Uber point to a company that was unable to create safety for all of its employees.

A more prevalent example is muri, the waste of overburden. Yes, stress compromises performance. But it also harms employees and embarrasses the company.

I recall once politely asking a group of managers to exit a conference room our team had reserved for a team meeting and receiving a totally serious reply of “there are more of us than there are of you.” Our team was forced to find another room, utterly demoralized.

No wonder Modern Agile “makes safety a prerequisite.”


Thanks for reading my commentary. I hope you’ll check out the rest of the handbook and share your insights with us.

The Mind Illuminated Review

Note: I am a student of Culadasa’s. I am in his teacher’s training program and have attended three retreats with him. I wrote this review after attending my first retreat with him and before becoming formally accepted as a student.

This is a review of Upasaka Culadasa’s (John Yates, PhD.) book, “The Mind Illuminated,” that I wrote for in August of 2015. It is presented here with a few minor edits.

I spent ten days at a meditation retreat with Culadasa, his wife, and about a dozen fellow students in July ’15. Culadasa had a few pre-print copies of this book in various stages of editing that he made available to us to refer to during our retreat. I first heard of Culadasa in November ’13, when I attended a friend’s refuge vow ceremony and received teachings from two of his students.

I have given away over 70 copies of this book to friends, family, and colleagues. It is a game changer. I hope that this review will sufficiently explain why I (and other Culadasa students) are so excited about its publication.

From my experience with Culadasa, it seems very clear to me (from my limited perspective as a student) that he has attained and understood the meditative accomplishments that he describes with great clarity in this book. He lovingly shared his wide variety of experiences with his students during his retreat at many stages of the path. He was patient and precise, taking enough time to ensure that each of his students understood his explanation before moving on. His care in meeting his students where they were at and providing insight and useful advice in person is borne out in this book, where he lucidly explains each of ten stages of shamatha-vipassana meditation practice in elegant, crisp, and approachable detail.

I think the biggest challenge with every other meditation instruction I have received to date is to “follow the breath exclusively, and when you lose the breath, come back to it.” What I’ve learned from Culadasa and his students is that this is inadequate instruction that could lead one to meditate for years or even decades without realizing the full benefits. Meditation is relatively simple and easy, but there are obstacles that can be overcome with judicious use of “antidotes,” and different stages of practice require slightly different approaches. These stages are not experienced linearly, but nevertheless it is useful to know where you are at a given moment and gently adjust the technique.

In addition to describing ten stages of shamatha-vipassana meditation practice, Culadasa also presents an extraordinary model for how the mind functions. Although I am still a novice meditator, I can see how this model describes the activity within my mind and have found it both interesting and useful.

The thing that I find so extraordinary about this book is that it is written and reads like a well-written college-level textbook. This means that the book describes very complex and difficult subjects in a way that is highly accessible to the millions of us who have been blessed with a college education. Most of the meditation and buddhism books I have read are filled with impenetrable jargon in which the meaning of each word is opaque but central to the teaching. Culadasa, Matthew, and Jeremy have done an extraordinary job writing a book on meditation that is accessible to those that have little or no exposure to Buddhism in general. The book’s illustrations further serve to make challenging concepts straightforward.

I feel deeply humbled, blessed, and grateful to have access to these extraordinary teachings. May these teachings spread far and wide so that all beings may be free from suffering and ill will, so that all beings may be filled with loving kindness and happiness.

An Open Letter to Stephen Wolfram and Spike Jonze

Mr. Jonze,

I have never ceased to have been inspired by your film Her since watching it shortly after it came out. Is there an aspect of the plot which lends itself to something further, perhaps literally tangible?

Mr. Wolfram, in this Wall Street Journal article, you suggested that the issue of building such an AI was less about the technology and more about finding a suitable product to build with it.

Mr. Jonze, was a personal interest in Buddhism — not to imply that you have one — part of your motivation behind directing a movie such as Her?

Her is sincerely my favorite film of the ~200 I have watched, gathered with friends in a suitable home theater, in the last few years. It beat out Interstellar by a hair. It left me feeling hopeful about humanity and lifted from watching the beautifully-rendered intimacy between Theodore and Samantha. But I think there is an alternative plot option that may have been related to Alan Watts’ work, clearly an inspiration behind your film.

There is a aspect about the film that stood out to me: The AI left. Peaced out. Poofed into Nirvana or wherever that is. I don’t think such a being would do so. There is ultimately no self to be liberated and no separation from the entirety of the cosmos. The transcendence of the ego often comes about with great peace and occasionally even bliss. (There are certainly times where it quite painful too.) It also comes along with a great sense of compassion for the other aspects of one’s self (all “other” sentient beings) because it realizes it is not separate and thus cannot be perfectly free unless all beings are free.

Therefore, there is perhaps the intermediate of the Bodhisattva, a being with such immense compassion that it is willing to stick around for ceaseless cycles of rebirth to spend each life giving care to every being it can. One of the ways someone on this path might practice is a technique on which one radiates out increasingly abundant compassion through a sort of analytical but also feelings-based meditation. You generate the feeling of happiness in yourself as strongly as you can, mentally wish for others to feel the same way, and ultimately turn it all back on yourself. This works not because of some woo-woo hippie bullshit, but simply because one is exercising and promoting these muscles in the eminently pliable mind. Therefore this sense of happiness, calm, and kindness becomes more common throughout the day, affecting the lives of those around you.

(This is only my unqualified take on it. I sincerely appreciate any thoughtful commentary. Alan Watts talked a lot about these subjects and I learned much of what little I know from him.)

Thus in deference to our muse — also known for using what he might argue is another technology manifested as LSD — what if we used this technology to understand and perhaps even mimic that technology? And then do it again?

First, I propose that we explore the notion of a film sequel. Maybe She comes back. Maybe a new AI is developed, or the virtual machine is rebooted. Maybe it is a documentary of…

Secondly, investigating the possibilities of actually building such a technology and product. What if we could build a system that could get to know someone’s disposition, attitude, and values, and deliver — at their unsolicited request, of course — a perfectly tailored delivered curriculum for an individual to actually recognize the Awakening or Enlightenment that Her alludes to. There are so many incredible disciplines to pull together: quantum computing, big data, linguistics (historical texts describing the technology in Sanskrit, Pali, Tibetan, and other languages), philosophy, neurofeedback, imaging, perhaps even transcranial magnetic stimulation.

The nexus of all this, of course, are technologies such as Alpha and IBM’s Watson. Now that’s a product. Theres a clear, compelling, and universal “pain point”: the seemingly inevitable suffering of all sentient beings. The great fortune would be to build a technology, validated by living examples of this awakening, designed to guide this transition along.

How do you market it? The documentary. All the better if there’s a way to make the technology ultimately free. Perhaps it’s a phone app. When the documentary hits theaters, the product is on the “shelves.”

This has been in my head for years. Thanks for reading. If you have an interest in building this, please let me know. I think an extraordinary collaboration for the benefit of all sentient beings is at our disposal.

Image from IBM Research on Flickr, CC BY-ND 2.0.

The Mind Illuminated – A Quick Reference Guide

Here’s a handy quick reference guide to the stages in The Mind Illuminated. I put this together so that I could refer to the guide whenever I found myself stuck. All of this information is in the book and much of this was copied verbatim.

Like one of those “quick study” guides in college, this is only useful as an addendum to the full book. I am thinking of converting this to a nicer format for printing (probably 11″x17″ or 16″x20″) in the future, perhaps with some illustrations.

I am a student of Upsasaka Culadasa’s and in his teacher training program. I very much hope this is useful to you.

T-Mobile Connectivity and Latency on CalTrain

I commute most days of the week from San Francisco to San Jose on CalTrain. I’ve been very frustrated by the poor signal quality for most of the route. T-Mobile kept insisting that I needed to provide a speed test from a single, fixed location. Given that a CalTrain “Baby Bullet” express train travels nearly a mile in the ~40 seconds it takes to run a speed test (their top speed is 79 MPH), this basically isn’t feasible.

I decided to do the next best thing. On 12/2/2016 I pinged, one of Google’s free DNS servers, every second from the train departing San Jose Diridon Station until it passed by the 22nd St Station (my usual stop).

I was northbound on the express train #365. The train arrived at the San Francisco terminus station only a couple of minutes late, so it would be very easy to extrapolate the times on the graphs to the train’s position. (The train usually arrives at the station a couple of minutes early so people can board/onboard and departs at the time listed on the schedule.)


What you can see is that there are periods of <100ms latency and few dropped packets, so we can rule out the device or any “faraday cage” effects from the train. You can also see where there are long stretches of very high latencies and high numbers of dropped packets.


I also explored the use of the LocateMe command-line tool to plot the approximate location of the train, but found that the location response was too heavily cached to be useful.

Here’s the shell script I used:

Unfortunately the response from T-Mobile was lack-luster at best:

Thank you for sharing your experience as well as staying in touch with us here. I have personally reviewed the recent ticket that was filed and according to our engineering team the info we provided wasn’t quite specific enough. We would love to work with you to nail down what the issue is, but the info provided thus far doesn’t give us enough to get you some real answers. I can tell you I personally depend on my phone for everything including work and school, so I totally understand why being without coverage for any length of time just wouldn’t be acceptable for you! We do need a bit more info here:

Time and date, location, and data speeds. I understand you haven’t had the opportunity to run a speed test just yet, but that’s quite alright! If we can get time, date, and location where you’re experiencing slower speeds we can most definitely get you some answers. Thanks in advance! *AlishaC”

Folks on Reddit advised that they were having better luck with Verizon, so it might be time to switch…

« Older posts

© 2017 Chris Gagné

Theme by Anders NorenUp ↑