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


52

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


20

Your problem is not that you have developers and non-developers (as you call the business analysis/product owner, the designer and the testers). Your problem is that these people have individual ownership on their slice of the cake and not on the entire cake. Here are a few things from the Scrum Guide (emphasis mine): Development Teams are cross-...


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

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


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


16

Your team appears to do mini-waterfall development within each sprint, which is a known anti-pattern, as you don't get the collaboration within the team that make agile methods successful. Also, Scrum only has 3 "job titles": Product Owner, Scrum Master and member of the Development Team. There are no separate developers and testers, they are all equally ...


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


10

You are doing a lot of good things already, but I would also recommend the following: Reduce how much you bring into each sprint Keep on reducing it until the testing bottleneck disappears and the team completes all the work they allocate to a sprint Continually reinforce the point that the team's job is to deliver completed items, not to do lots of coding. ...


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

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


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

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


9

You asked in terms of scrum, so that is how I'll answer. However, there are a number of red flags in your question that lead me to believe you aren't actually doing scrum (and I am far from a scrum purist). The scrum answer would be: as PO, you are responsible for the product backlog and priorities, not for process improvement. If you see an issue, you ...


9

Other comments here all ring true: too waterfall-y, not enough team responsibility, etc. but I'd like to emphasize a point made just once in other answers: you're absolutely setting goals too high. You HAVE to set bite-sized goals that are achievable, no matter how slow that is. If that doesn't fit the business schedule, the business schedule cannot be met ...


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


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

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


6

The first question I would want to consider in your position is: Are the issues being seen in test because the code is unreliable, or because the requirements have not been understood? The developers are presumably getting bogged down in ensuring the correctness of the code, but of the following two scenarios: The developer writes what they think should ...


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