Should you write down a list of issues, or fix issues as they arise? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

I have observed a strange trend in the company I work at.

There are people who insist that there should be a list of tasks. They estimate those tasks, implement them, and try to meet their commitments. However, while they are coding, the requirements are likely to change. The priorities shift, the tasks increase or decrease, and the scope may just down right change, causing the whole work to get discarded.

And then, there is another team, who meet issues and fix them as they arise. There are no estimates, there are no priorities, there are no set deadlines, and mission statements for sprints go something like, “Fix the bugs in the [insert subsystem name here]”.

Now, which is the right way to go about being agile when you have technical sprints that focus only on stabilizing the system? Should you try and gather a list of issues, only to have them change, or should you try and fix-as-you-go, without saying when you’ll be done?

Answer 1

Both methods have a lot going for them, depending on the context.

If you're fixing bugs that block the user's experience, then it is very hard to give a good estimate because clearly something is happening that has not been anticipated. It may turn out to be a one-liner, or a subtle misunderstanding that needs hours if not days of tracking down through event logs and stack traces. You probably also know that it simply must be dealt with - these bugs appear as top priority and stay there until the end user can proceed again.

On the other hand, performance enhancements, some stability enhancements and aesthetic changes - things which degrade the user's experience but don't prevent him using the application - can be treated much more like feature stories. You decide which ones will make the most improvement for the time invested, and review that decision regularly in the light of other changes. Users may find workrounds. The stories may even be rendered moot by changes from the emergency bug fixers.

Ultimately there isn't a unique "right answer" - just find what works best for your teams.

Answer 2

I've been doing XP for a few years now and I find this discussion a bit off. I've never done a sprint that focuses on bug fixes/stabilization; I've also never fixed bugs as I find them.

Instead, I've always followed a standard process:

1. If the bug is in the code I am working on, I fix it. I'll also log it and isolate it in SCC so that the bug fix isn't treated as part of my story.
2. If the bug is in another area of the app, log it.

That allows you to finish your story without constantly being interrupted by other tasks. Without this type of discipline, estimating is near impossible because how long a task will take depends upon the size of the tasks AND how many bugs you'll find.

Additionally, by recording the bug, you allow: 1. All bugs to be visible to the entire project team. 2. Let developers group bugs when working on them. 3. Anyone, not just developers, to report (and record) bugs. 4. Bugs to be prioritized with user stories which means priority is getting established by your

Product Owner instead of by the dev's.

Answer 3

I think this boils down to how development as a whole is understood. If "just getting it done" is the goal, then fixing bugs as they appear may well be the course of action. Also, to avoid wasting time, if you see a bug in code that you already manage AND you already know the fix, I don't think there is much point in creating an issue just to close it a minute later. This bears a risk, though, which the other folks try to address: You'll never get things done if you constantly change the goals.

Consider an agile sprint or a planned version. Both usually set what features to implement and what bugs to fix. It's important to stick to those set goals in order to actually achieve them. Even if you don't create issues for bugs you fix during your development phase, they cost you time. And that's time you might not have. Obviously, you know those bugs need fixing. But even for your management, it's often probably easier to explain to a customer that another release cycle of a week or two is needed in order to get everything bug-free, than to explain why all deadlines were missed. If people depend on releases, development should work toward them and appreciate that no release ever will be perfect. Seeing a bug is half the battle.

Rethink your last paragraph. Creating new issues does not change the list of things you're currently working on. It only changes the backlog that may or may not need addressing (possibly depending on the outcome of the current sprint that you get done in time).