Regarding the Edit button issue, we added that to our own software a year ago and our clients hate it, just like Mark mentioned above. Can you set it up so that once the record is opened that the user can enter edit mode if they double-click on ANY field on the form?

Is Priority the only column that does this? Why can’t I do the same with Workflow Step, for example?

Also, is it possible to configure so that a double click on an item in the grid goes right to edit mode? It is a pain to go to view mode, and then have to go click the edit button.

Mario Piccoli :
Will the 2012 version support TFS integration?

Yep we are using TFS also. Integration with Ontime would be great.

The performance is amazing – it’s fast and reliable.

Mario Piccoli :
Will the 2012 version support TFS integration?

I second that – we use TFS and OnTime and they need to talk to each other

It appears that your perspective of SCRUM is a lot close to “traditional” project management than SCRUM is ever intended to be. I can tell that yout experience with scrum has been with larger organizations that have had to adapt traditional project managers into SM and PO, etc.

For example, your reference to the role of a SM as one who more or less stares at a burn down and tracks progress grossly under-characterizes the role. SM are pigs that protect the team and help the team voice their concerns and questions. They work with the team to pull in resources from the organization and most importantly remove impediments. This role has less to do with project management and more to do with leadership. After all effective teams don’t need to be tracked, they can do it themselves.

Also, why should bugs be tracked in a special backlog called a defect backlog? Is a bug work? Why is it grouped separately? I do like your comment about how bugs that are part of the sprint need to be fixed in order to be considered done.

Also, the release backlog is also kind of strange. I don’t know how Rally and other software vendors get into this mess (same with a defect backlog,) I get that large organizations have larger less frequent releases, but effective teams release smaller chunks of working software more often, making the concept of a “planned release” a foreign one. In my teams I have released software as soon as it was accepted, this means we release 20+ times a day if needed.

Anyway, thanks for posting and good luck with your scrum tracking tool!

Paul
peppyheppy

Lacking:
* Sprint Review
* Sprint Planning
* Backlog Grooming (now a required component in Scrum)

Problematic:
* There is no such thing as a “Release Backlog.” Further, when you talk about the “goal of a release” you state that is feature driven, which is not always true. Sometimes it is date driven, and most practitioners seem to prefer date driven releases. More here on my blog:
http://www.scrumcrazy.com/Tips+for+Estimating+Release+Dates+and+Release+Scope+in+Scrum
Frankly, because Release Planning itself is no longer part of Scrum, I’d just prefer you keep it out out of the picture altogether.
* What is the deal with the comment about the Product Owner being a dictator?
* SM – “…sets up meetings and monitors everything…” — this is not an accurate portrayal of the SM — I’m ok with the other text about the SM.

Having said all of that, I really love the diagram’s concept and presentation, but I will never use it because it is just too inaccurate.

If you’d like help improving it, I’d be happy to help.