- People may accuse me of being too unwilling to bend from the original tenets of Scrum, however, here goes.... I ve also seen the concept of managing a productMessage 1 of 1 , Apr 29, 2008View SourcePeople may accuse me of being too unwilling to bend from the original tenets of Scrum, however, here goes....I've also seen the concept of managing a product backlog and a "technical backlog." It seemed logical when it was created, but in my opinion, it often resulted in developers taking responsibility away from the product owner to determine what would be worked on during the Sprint and what would not. The product owner was often in the dark regarding these technical items and felt (rightly) that their responsibility for the product vision and direction was being usurped.Accuse me of being too orthodox if you choose, but there's a reason why the product backlog is a single list and why it contains everything from features to defects to complaints about the product behavior to, well, you name it... There was never any specific demand that every backlog item have a positive customer value -- just that it describe something that needed to be done to the product.By having a single list that everyone can contribute to, communication is established across all of the roles within Scrum and everyone has to collaborate to get the right things done at the right time.Two lists invites confusion, frustration, and...gasp!...more lists.I also understand where Tobias is coming from....experimentation is good. Try it if you want to...nobody's going to tell you that you can't. However, remember that a lot of how Scrum works is ALREADY the result of lengthy experimentation. Don't discount that fact when you look to change the basic concepts.Keep it simple. Scrum is simple in description but complex in operation...don't add to the risk by adding to the complexity.Jim SchielCST, Danube Technologies, Inc.
On Tue, 29 Apr 2008, Michael James wrote:
> As Tobias alluded, there's more than one way to skin this cat.
Sure. What i forgot to mention was that the team is distributed (see
previous posts for some details). So the thing with the post-its
doesn't work too well :-)
> If you need help convincing people technical debt is
> real and important, see Kane Mar's paper (capturing
> ideas expressed by Ken Schwaber, Jeff Sutherland,
> and others):
Actually, the PO (for now at least!) recognizes the need to fix some
of this stuff. I was more interested in practical ways to 1) Collect
the information, 2) prioritize with the other backlog items etc
I think we'll just start out by maintaining our own backlog of
technical tasks (similar to the post-its, but without the nice
physical touch :-).