Death to the Product Backlog!

This week, our Client Services department is adopting Scrum, and it is already working wonders in our design department. As I work with these teams to assist in their Scrum education, one phrase keeps coming back to me time and time again: "Death to the Product Backlog!"

Now, I know this is a rather odd stance for a Certified SrumMaster, but it is necessary, so I shall proceed.

In Ken Schwaber's paper What is Scrum?, he defines the methodology as...

"...a simple set of practices and rules that encompasses the transparency, inspection, and adaptation requirements inherent in empirical process control."

Both the Scrum Alliance and Ken's site, Controlled Chaos, add...

"Scrum is an iterative, incremental process for developing any product or managing any work."

The kicker lies in those last three words.

If we are to truly use Scrum as a management methodology—as opposed to a engineering or development methodology—then there is no product, only a list of tasks to be completed.

With this in mind, I hereby propose that the Product Backlog be renamed Project Backlog.

Additionally, that rule about each sprint producing deliverable product seems counter to "managing any work" as well. I submit that the Sprint Goal or Objective agreed upon in each planning meeting solves the same problem this rule sets out to accomplish, therefore the redundant deliverable code rule should also be put to death—finally allowing everyone to manage anything with Scrum.

Afterall, it is the transparency, self-management, team-accountability and trust, (coupled with inspection and adaption) that make Scrum work. None of these require a product—just identifiable and deliverable tasks that support one goal.

Now, who's with me on this? Do we need a petition? What are our next steps to correcting this oversight? Maybe, we could start an Americanized version of Scrum. Yes—that's it!—we could call it Huddle. What do you think?