How Sprint works [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 2 years ago.

Improve this question

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?

Answer 1

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.

Answer 2

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.