We started to use this tool and feedbacks from team are very positive. The tool is simple to use and install but it follows SCRUM principles. We like intuitive GUI as well.

The tool is easy to use, team likes it. Our stand up meetings are more effective.

That is an great tool for easy project management using story cards on the task board. It also supports collaboration and scrum metrics.

This article tries to take a traditional PMI world-view and map it onto Agile methods. It totally misses the mark on some of the key assumptions of agile, particularly Scrum: that many outcomes and benefits of a project *can't* be quaitified at the beginning of a project, and that the requirements and deliverables will change over time as the team learns and adapts. The writer apparently has never heard of TDD or CI - quantification of progress and performance is part of every agile project I've ever worked on. Finally, the author proposes an external definition of quality, rather than one that's defined by the team and the product owner. That may be preferable in an academic setting, but it's not always relevant in a business setting.

Perhaps I missed it, but what is the difference between being a very strict on definition of "done" (calling it a "production ready code" as Kane Mar does and Running, Tested Feature as defined by Ron Jeffries? I understand that in case of huge legacy burden you need to incorporate your feature into the definition of "done" might be a little weaker letting Product Owner to decide (acceptance testing). But what the heck should I measure then? Number of accepted-not-necessary-running features? Thoughts anyone?

Mmm. I think the Extreme Planning folks totally missed it. I think it introduces some significant problems if you are inheriting legacy applications, like almost 100% of everyone. Much better paper is here: http://danube.com/blog/kanemar/determining_project_release_dates.html (release planning) or here: http://danube.com/blog/michaeljames/Sprint_Burndown_Chart_vs_Product_Release_Burndown_Chart (what mertrics are to be used where) Basically, Danube's site is the best resource on the net for this stuff, imo Anupam

See also very similar article at http://www.gantthead.com/article.cfm?ID=235263

Oh, and I don't really care if it's still Scrum. The truth is that sometimes using a shiny brand name with glossy banner helps to get management buyout.

Interesting observations indeed. Also I recommend spending some time reading the replies to the original post on Tobias' blog. Personally I coach the teams to shorten iterations not only for business but also for plain educational reasons. Sooner they could have the retrospective, more often then have planning sessions, the sooner they become familiar with the approach. Also while working in a corporate environment, in a company that has heavy waterfall background I learnt that using hours (or days or whatever that has something to do with time) as the estimation unit is lethal during projects reviews. I believe the more abstract the unit is the better for the team and easier to get the management to understand. I often pick up apples...