Hi there

Can anyone please explain what a backlog for agile management must have?

(Heh ...)

A backlog is a backlog is a backlog. It is a set of objectives that the team (leadership ...) has consciously identified to be set-aside for some period of time, either because resources are not available to handle it now, or because of scheduling conflicts.

Also: Pragmatically speaking, "agile" translates to "staged delivery." Nothing more or less. The team (management) carves-up the project such that something truly-useful, and truly-meaningful, can be delivered to the (internal or external) customer on a regular basis. (But not arbitrarily, e.g. "every two weeks," which is meaningless.) This is the one-and-only "grand promise of agile" that actually survives for any length of time in any organization that I've ever witnessed which tries to be "agile." However, it is a very useful (and achievable) goal.

Other things are "not-so-much.' For instance, it doesn't really matter if you stand up or sit down, and "moving yellow sticky-notes on a white board" is mostly a symbolic gesture. Likewise, you won't ask a real business-partner more than twice "is this what you want?" (They've got plenty of their own job to do, without getting involved in how you do yours, if you know what I mean.)

"Agile" really has just one truly-useful idea that can be reached. However, it is a truly-useful idea, and it can be reached. Which is a lot more than you can say for a lot of other "project management" principles. (And I think that I can safely say that, because "project management," and "project management consulting," is most of what I do these days.)

1 members found this post helpful.

you have my deepest sympathy

The only thing I would add to sundialsvcs excellent summary is you MUST HAVE an understanding client/customer. If they don't understand what you're trying to do with agile (or your implementation of agile), you and your backlog are in for a world of extreme hurt.

Yeah. Of course it is possible to make a decent living managing this divide between the clients (who really only understand or want to understand the deliverables) and the developers who really, really want fixed-length sprints. It always amazes me how few people can speak to, and work with, both groups.

And this is precisely why Agile fails!

I never go to Home Depot, nor to Lowe's, whenever I want something to be done to my house. "No, Sir, I do not claim to know shit about Construction! However, I have cash, and, with that cash, I mean to hire Someone (You!!) who damn-well does!"

Indeed, I have, over the course of a great many years now, succeeded in hiring competent (licensed ...) contractors who were exactly the Professionals that I sought. They did their work competently, and left me with a stack of business-cards. I dutifully (and happily ...) handed them out.

"Pardon me, but ..." my expectations regarding those people was never that I would have to understand their business in order to successfully talk to them, nor to contract with them to "get what I wanted, with a warranty." No, sir ... I fully expect them to be fully-competent at what they do for a living, just as I am competent in mine. I therefore will express "what I want done" in my frame-of-reference, and if it should be the case that they (happily, unbeknownst to me ...) require additional information, I shall require them to ask it of me ... and to do so in terms that I understand.

If I felt that I had to "be understanding" in order to successfully contract with any particular expert, then I would know only this: "that I am not talking to A Professional In His Trade," and that I should forthwith (and, without delay!!) hang-up and move along to the next name on my list.

And if you (whoever You are ...) imagine for even one split-second that your customer's expectations are anything(!!) other than this ... you've been sucking-up far too much self-indulgent "Agile Juice!"

"I have money, and I will find c-o-m-p-e-t-e-n-c-e ... and a w-a-r-r-a-n-t-y ... one way or the other!"

Inside or outside of any organization, the expectations are ... identical.

... as well they should be.

why is this discussion in 'programming' ?