I am not from a IT background. An idea is generated is being worked upon now. Initially we started with Waterfall methodology and now using agile. Want to understand how exactly this agile methodology works. Please don't consider my questions in a wrong way. Request for your inputs.

  1. There is a bug found in between of the sprint which was not there previously. This may have happened due to the features being added in the current sprint. Now should a PO write a story for the same and wait till the next sprint?

  2. Should every sprint be created assuming a capacity to handle bugs which are created/ coming up due to the new features added? Understand the team has to look to avoid bugs but what is the solution here?

  3. The backlogs taken in a sprint is not completed and it is just carry forward to the next sprint. PO or anybody can not tell anything considering this is how agile methodology works. Is it true?


Let me start by saying, you have not specified a methodology. Agile is more of a type of way of doing things, a philosophy if you will. As such, there is no "Should do this or that".

You want to work in sprints. This means you are timeboxing your efforts and you do what you can within that timebox. Within a sprint, you would be wise to allow for testing and fixing bugs for whatever work you've done.

Now, there will come a time where a bug is found after a sprint is complete or for even older changes. For these bugs, there are some choices you can make. I'd say, first of all, you'd want to assess the impact of a bug. If there is an acceptable workaround or impact is low, then you can decide to plan to fix this bug in a sprint.

If the impact is high and no acceptable workaround can be devised, you probably want to fix it as soon as possible. The way I would do it is to take the needed capacity from the sprint and fix the bug. Then accept whatever impact it has on what can be delivered from that sprint.

Depending on the complexity of the bug and the amount of time needed, you may want to consider first building a workaround if you can and fix it properly in the next sprint.

As to writing user stories for a bug, I'd hope whomever reported the bug or took the report from the user, will have reported a reproduction path and expected behaviour at that time, so no need for a PO to actually write anything.

| improve this answer | |

The thing you have to remember is that the purpose of sprints is to help you set and hit deadlines.

Essentially you are trying to work out how quickly you can program 'features'. Then you can take your list of features, multiply it by this 'velocity' and say "we should be done by this date, therefore the cost of the software is X"

AT the start of a sprint, you take a bunch of features and say, "yeah I recon we can do these in one sprint". At the end of the sprint you say "hmm looks like we were off by X% on our estimates! better factor that in next time and tell the customer we might be late!"

The reason you group things up into sprint rather than each individual task, is because there is a lot of interplay between features when you program them. Its easier to lump them together when you program and estimate.

If you add or remove stuff from a sprint you throw your numbers off and push back the dead line. Sometimes something will be important enough that you have to take the hit. But you should avoid it if possible.

Some people do leave x% free for unplanned stuff, but in my view it doesn't really work. You are just adding a fiddle factor into your estimate calculation. "Oh we didnt get it all done, but that was because there were more bugs than expected." well was it? you just cant tell really.

The worst thing that can happen is that you constantly add and remove things from the sprint in progress, so you never really know whether your estimates are any good. When the deadline comes around you find that you have loads of the originally planned features still to do.

Its much easier to leave all those bugs until then end and have a limited known set of bugs to clear up. At least you will only over run by a known amount.

If you are worried about the delay between finding and fixing a bug, and it can be a long one. The the best approach is to do shorter sprints. A 2 week sprint means 4 weeks before a bug fix is released. A 1 week sprint means 2 weeks. its a big difference in turn around.

| improve this answer | |
  • You can't expect an x amount of bugs, however, you can expect bugs to happen. So no, there can't be more (or less) bugs than expected. You can measure the amount of time spent on bugs, though. If you have factored in x% for bugs, you can calculate the amount of time you leave open for bugs and you can calculate a deviation from that amount and tweak accordingly. – Jonathan van de Veen Feb 27 '18 at 8:48
  • In reality, customers might not accept waiting even two weeks for a bug fix. They may not even be able to if the bug has a high enough impact. In that case, you have no choice but to drop everything you are doing and fix that bug ASAP. – Jonathan van de Veen Feb 27 '18 at 8:50
  • Maybe in a perfect world. In practice its hard enough factoring in simple things like having less people one sprint or unexpected meetings. Throwing bugs in there is just lack of discipline – Ewan Feb 27 '18 at 8:51
  • In reality those customers might have to wait two weeks regardless of how soon you start work on the bug. "dropping everything" is occasionally necessary, but its lazy project management and damages your long term performance – Ewan Feb 27 '18 at 8:53
  • If you wait two weeks to start the work and then you need another two weeks to fix the bug, doesn't that mean a four-week wait for the customer? I don't know about your customers, but none of many the organizations I've worked for would have accepted a two-week turnaround on a serious bug in the first place. I agree that having to go and fix bugs, hurts the team's performance in implementing new features. However, losing customers because of poor support will hurt the business as a whole. I know which I would choose. – Jonathan van de Veen Feb 27 '18 at 9:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.