Hot answers tagged

77

And not only are they suppose to correct them, they are suppose to correct them on their own time without impacting plans. This is your problem. Why don't your plans include the time for fixing bugs that you know will be there? We all know it's impossible to write perfect code. We all know that bugs inevitably creep in. Expecting engineers to fix their ...


51

Just as a side note to the other good answers - developers tend to have minds that look at process and (un)consciously find ways to game it. What you are training your developers to do here is to not raise tickets for defects they find when they are developing (as either they, or possibly worse for them, one of their colleagues) would then have to work late ...


45

Over the last year we've become pretty hardcore in adopting the principal that an engineers must fix their own defects (those found internally and those that escape to the end users). Not only are they supposed to correct them, they are supposed to correct them on their own time without impacting plans. Let me ask you a question. Whenever a plan changes, do ...


27

This is a troubling post. Your company is penalizing its workers for what is a normal and expected occurrence--performance variability. The whole reason to "punish" someone is for a behavior change, to replace a maladaptive behavior with an adaptive one. In this case your punishment will yield nothing because we do not have the capacity of reducing ...


17

Where Does Technical Debt Belong? Should these issues be grouped under user stories / child tech tasks and be accounted for within the sprint process? No. Oh, there are some cases where some small tasks need to be added to the Sprint Backlog in order to meet the Sprint Goal, but only stories accepted from the Product Backlog by the Team because they ...


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


17

Aside from the main issue you are asking about, there's also something a little concerning about this part: "defects (those found internally and those that escape to the end users)" I don't see anything about QA being asked to create the missing tests on their own time. This (assuming this is correct) along with your main concern demonstrates to me that ...


15

The short answer: No, it isn't! The not-as-short answer: Your company has come up with the idea that the existence of bugs is a professional failure on the part of the developer. This is not true. All code contains bugs. Quality code contains fewer bugs. Your developers are doing quality work for you when they find and fix bugs. This is them doing their ...


9

Essentially, I want to be able to demonstrate the effectiveness of the recent time that we've spent dedicated to bug fixes. It's obviously good news that you've fixed all these bugs, but as a manager/senior stakeholder my first question would be why there were so many bugs to fix in the first place. Because of this I'd suggest that in addition to ...


9

My opinion is that you have a very good approach at hand by creating separate swim lane for bugs/issues on the same wall/board. Visibility is the main reason why I am inclined towards this approach. Having two separate systems to manage your to-do list is not going to give you a complete picture of the current status. Visualizing the flow of work and ...


9

"Hardcore" indeed. I don't have much to add to the other good answers, but I'll relate an experience of my own as a developer. I worked for a company in which the culture was similar to what you are describing, in that there was heavy pressure to work long hours and weekends without pay fixing stuff that we'd been required to produce in unreasonably short ...


8

With my team we recently adopted a new bug-tracking tool based on a criticality matrix. This is a physical board representing a 4x4 matrix on which we stick notes according to two criteria: Columns represent the intrinsic severity of the bug. The more a bug is on the left, the more it is critical. Each column has its own explicit policies but, for example, ...


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


8

TL;DR You have an X/Y problem created by skipping over analysis of the process problem in favor of a tools-based approach. JIRA and GitHub Issues are tools, not processes, so until you fully define your process flow you will remain at disadvantage. You need to define what you are tracking, why you are tracking it, and how you will use the tracking data to ...


8

It reassures your stakeholders that the bug was, in fact, fixed. It might help them understand what was wrong in the first place, and therefore why it was prioritized. In some cases it could prompt a broader conversation about desired behavior, edge cases, possible new functionality, etc. Remember, the goal of the demo/review is to use the recently ...


7

Every task that the team is going to perform should be documented and accounted for in each sprint. Whether it is a user story, bug, or technical debt, every item should be assigned appropriate points so that the team continues to monitor its proper velocity. Another advantage of this is that all the stakeholders know that is being done and why. For the ...


7

Stuff like that should be in the working agreement of the team. There is no right answer on how to handle the situation but there are pros/cons of creating the story/defect and/or underlying task. Pros: Creates visibility for the rest of the team Leaves an artifact that the work was done Cons: Administrative overhead associated with creating/managing the ...


7

TL;DR Even when the change is apparently minor, it can have ramifications. The "one-minute fix" to some CSS class might impact the user interface (UI) on some other page the developer isn't thinking about, or might break important regression tests. This is the very definition of cowboy coding. More importantly, bypassing the agreed-upon workflow is a ...


7

This practice is good way to drive out your best and brightest, leaving you with a skeleton crew of your bottom performers. I have developed software for generation 4&5 fighter jets and managed software-intensive programs for the USN: PMP Certification, multiple graduate engineering degrees, Eagle scout, yada yada, yada. The original posts leads me to ...


6

How do we capture enough details so that in a month or so, when someone in those discussions comes back and their memory of it was different from ours, we don't get into a debate/discussion over whether it is a new story or a bug because we didn't implement right in the first place? You and the customer are currently trapped in waterfall thinking. You're ...


6

In addition to others, I also find this post disturbing. I've seen Project Managers want to place all sort of metrics on developers, but never on themselves, Product Managers, QA, management, etc. It takes more than software developers to release a project and get it right. Do you keep track of what was the root cause of the bug? Who has to work on their ...


6

This sounds like a good topic to bring up at the team's retrospective. There are lots of possible approaches, but the team should decide for themselves. Some things you might consider: The QA shows bugs to the Product Owner before they log them If a bug is not viewed as important by the Product Owner, resolve it as 'won't fix' Discuss as a team the types ...


6

Outside of the Jira context, an Epic represents some kind of deliverable business value. An Epic is usually made up of good Stories, the full value is realized to the client and users after all of the stories are completed and delivered. Not all Stories need to be part of an Epic. I would also say that other types of backlog items, such as items that ...


6

Welcome Ayesh! You have 3 options, and the best option to choose will depend on the details of what is going on: Ignore the critical bugs for now. Finish the sprint you're doing now, and put the bugs at the top of the backlog to be worked in the next sprint. This can be a good option when the sprint is going to be complete in a few days anyway, or when ...


5

We use a different color of token to represent bugs. That gives us a quicker way of looking at what proportion of the current work is for features vs. bugs (and same for the backlog of items). We also have the separate swimlane as others have suggested. But if we come across a bug that is related to a feature that we are working on, we put the bug in ...


5

The first thing to remember is that points != time; points are a relative estimation of complexity. While you could get a sense of hours-spent-per-point using the length of the sprint and velocity, that's not the purpose. Tthe way I typically handle sprint planning for an environment in which customers will inevitably be reporting bugs against software in ...


5

Does it matter how you name it? All extra work is new work when you look at it from a grammar point of view. You found work that first was not expected (or planned) in the form of a defect. I guess your question comes down to 'how to handle defects? in an Agile environment' I think there is only one 'correct' (very opinionated) way: Always place defects ...


5

Focus on your Definition of Done and work to it. The key to Zero-Bugs is not in a wicked triage and fix process, the key is to not introducing them in the first place. This starts with having a good definition of done, which includes all the technical steps to ensure the best code quality. For example, code reviews, automated tests, writing tests first and ...


4

The first reasonable step is to learn more about the issues the customers are having. In cases like this the general advice is to collect as much data as possible. Add google analytics events to everything you can think of, take the web server log files and try to recreate the steps the users are taking. With this approach you don't have to try to recreate ...


4

TL;DR Do you think it is worth to put up such a title formalism in place? No. A title is rarely a unique identifier across bugs, nor is it likely to communicate enough on its own to justify the constraints. Titles Should Be Meaningful While I agree that titles should be meaningful, it is very difficult to create a short formalism that could be ...


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