The Agile School

Scrum/Agile demands frequent delivery of software. Most of the companies develop software in a sprint of two weeks. ( How to choose Sprint duration? ) But many companies don’t release software that frequently. According to scrum principles software at the sprint end should be of shippable quality. But really is this the case?  Many teams who diligently deliver the software periodically complain that because of frequent release they are not able to fix all the bugs. Because of the number of bugs they have an affinity for longer sprint cycles. But in reality there is no co-relation between the sprint duration or release duration and the quality of the software produced after each sprint. Slow down to move fast If you or your team is in a vicious cycle of releasing software with bugs release after release – then stop what you are doing, review the process you are following Review the definition of “done” – Schedule a meeting with all stakeholders, decide on a definition of d...

• I can push bugs to backlog. • We can complete a story without fixing all the bugs • I have to finish all the stories first; the bugs can be fixed later. • Before the release I will have a maintenance sprint which will have only bug fixes. The list is big. If you are doing anyone of the above please stop doing it before it is too late. One of the fundamental requirements of scrum is to have a shippable product by the end of the sprint. There is no benefit in "finishing" maximum stories with lots of bugs. Scrum places high importance in the quality. With this approach of not fixing bugs will lead to accumulation of bugs & in few weeks you will have 100 + bug and you may spend couple of months fixing it. The cost of pushing bugs sprint after sprint will increase exponentially. The bug which could have been fixed in 30 minutes today will take couple of hours after 2 months!!! I have faced this problem in many teams I have worked with. My simple advice is to sl...