jvizueta / mantisbt

Mantis Bug Tracker (MantisBT) for the Lean Enterprise

lean-mantisbt

Mantis Bug Tracker (MantisBT) based on Lean Principles:

• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• See the whole

My own principles based on this:

• Less is more
• What doesn't help is an obstacle

mantisbt's Issues

EliminateWaste: leave only indispensable statuses (new, assigned and resolved)

More statuses means more bureaucracy

Why is it that I think we don't need other statuses?

• Feedback status: If we need feedback it means we can not reproduce the issue reported, so issue should be resolved with resolution "unable to duplicate" or any other that acommodates to the specific scenario, otherwise using feedback status will only affect service level statistics. If user wants the issue to be resolved, he should clone the issue, and fill a more complete description
• Acknowledged and confirmed statuses: plain bureaucracy. If you really need these, add a custom field of type list with these options and any other you think you need, I think no status is really needed here whatsoever
• Closed status: plain bureaucracy again, resolved is the new "closed status", if user doesn't agree with resolution she can always clone the issue. As the workflow is so light, her new issue should get assigned really soon.

EliminateWaste: disable fields unneeded

• Additional info: put it in the description
• os: nobody fills that anyway, if you do put it in the description
• os version: nobody fills that anyway, if you do put it in the description
• platform: nobody fills that anyway, if you do put it in the description
• steps to reproduce: nobody fills that anyway, if you do put it in the description
• severity: just put it in the description
• view state: I've never seen anybody use private, just leave it off by default
• priority: priority set by final users is not to be trusted, they all think their issues are very important, in a lean environment all issues should have a short time of arrival, if you really still think you need to set priorities, use a custom field that only certain access levels have access to, those who are supposed to set priority indeed, not any reporter, but a manager instead
• product build: based on a continuous delivery principle, you'll have lots of product builds, don't even botter to use this
• product version: based on a continuous delivery principle, you'll have lots of product builds, don't even botter to use this