16

Working software over comprehensive documentation. In general, I'd say that it just gets fixed and considered part of the work needed to complete the story. When you found the bug, you added a failing test to document it prior to fixing it, right? Right? Thats more than enough documentation for most use cases and doing anything more is useless overhead. (...


8

I love defect management, it throws up some wonderful logic problems :) What actually is Criticality? If you could define that then you would know the answer. I believe it is the combination of Severity and Priority, both of which should always be defined independently in defect management. The severity of a defect, i.e. the impact it has on the ...


4

The root-cause analysis is not the only problem solving method, and the solution process may include root-cause analysis or other methods. So, a solution idea can be found using any method. That's why accepting the problem and starting to solve the problem, and coming with a solution idea to the stakeholders is the accepted answer. Root-cause analysis is ...


3

Super-Short Summary The criticality of an issue is contextual, and can change over time as well as due to framing or extrinsic factors. I describe some silly but illustrative examples below, as well as a couple of more practical considerations of "value." When is "Critical Bug" Really Critical? Imagine you have a new phone app, which has a serious bug: ...


3

It's a PMP test question. The answers are not always logical nor based in reality. With this question, #3 and #4 are likely happening simultaneously. In fact, a solution may not be present without the RCA being completed; however, the solution provided to management may include an RCA being conducted and completed. So what PMI is looking for here is ...


2

Defect is a gap between actual system behaviour and expected by user. Defect criticality is a size of this gap. Either system behaviour or user expectations change - so does defect criticality.


2

TL;DR Yes. Under your current contract and within your current process, you should pay the vendor for all work completed. Unless you have a fixed-price, fixed-scope contract, all the problems you've described are process issues for which your company (rather than the vendor) is responsible. You are having difficulties because you are treating the offshore ...


2

In a real-world life environment (not the PMP exam), would it really be appropriate to come up with a solution before doing root-cause analysis? Yes. Because the customer is interested in a solution, while you are interested in a root cause analysis. And if so, how are you supposed to determine a solution, if you haven't even figured out the root-cause ...


1

I doubt there is any absolute rational. However let's look at it from a different perspective. Let's agree that there are showstopper defects which must be corrected before the current version of the product can be released. On the other end of the spectrum there are trivial defects which don't really impact the product and may never get fixed, such as a ...


1

The answer to this question has nothing to do with Scrum or any other type of development method. It's a contractual issue. A fixed rate per individual plus a listing of tasks is a time and materials agreement. That means, every burned hour against a task to your product is your liability. However, it also means that you should be involved on a daily ...


1

A project manager is responsible for ALL of the items that need to be accomplished, regardless of their "size". So there really isn't a "minimum threshold of work" before an issue should be tracked. The easy answer is to enter these small items in your issue tracking database. I'm assuming that your "project management worklist" is your issue tracking ...


1

It seems that an initial problem evaluation took place already. Otherwise one could not say something about the dealy. Due to the fact that a crutial part of the software is affected, the stakeholder will probably have a high interest in the topic. Fore sure, you habe to assure that a similar problem will not occur anymore (at least reduce the likelihood). ...


Only top voted, non community-wiki answers of a minimum length are eligible