17

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. (...


12

We have an index card on our board, that permanently sits in the Backlog, labelled "Technical Debt". Any team member can grab a post-it note and write down T.D. they think we are collecting. For example, if they know that a coding decision could have complications later down the line, we stick it on the Technical Debt card. At the beginning of every sprint ...


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 ...


5

First on my list would be to take some time reviewing your recent bugs and doing a root-cause analysis on how the bug made it in. That can help you decide on which solution(s) make the most sense for you to implement. As far as things I would likely implement in a similar situation: Design reviews - As a short term solution, I would suggest simply having a ...


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

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 ...


3

I think Lunivore and durzagott give some great advice. The Technical Debt tracking is very smart. If something doesn't rate more than a 1, you don't really need to over plan. A couple of thoughts to build on what they said (go read their posts if you haven't yet). 1- What is your Business Value? You mention how many of these things are low priority. One ...


3

It's all about choosing priorities and visualizing your work. Your scrum board doesn't have to be restricted to sized stories only. And, please, don't try to size non business value work. Many forget that the velocity is meant to measure the "business value" being delivered from the product backlog. This means that it is limited by all the other "stuff" ...


3

You say you need to work on processes over tools. Generally with successful Scrum, the individuals and interactions are even more important than the processes and the tools, so if the team are just calling out bugs to each other, and that's working, why not carry on doing it? At the moment, the lightweight nature of the interactions is probably giving you a ...


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: ...


2

Club them(such stories/tasks) together to form a lump which suits your team, according to relevant functional areas Then relate & prioritize them according to business value. This would require a lot of technical insight and an ability from the tech guys to advocate & convince business/PO that these stories ( e.g. long term tech debt , ability to ...


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). ...


1

In addition to Kyles list: Automated builds with http://jenkins-ci.org/. We used auto-build triggered after each commit to main repository. Jenkins checks codding standards, triggers unit tests, functional tests and emails errors to team leader. Automated deployment. We use scripts to update production files. If something goes wrong we can use rollback, ...


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