Know agile. Not habit. (जानामि Agile न च मे प्रवृत्तिः)

What is cycle time: It is time needed to complete a function/task from start to finish. If some one tells you "you can complete the feature faster by writing unit tests" what will be your reaction. Probably you won't agree to it. It is counter intuitive for someone not initiated into TDD. How come writing more code, reduces total time for development? Let me start with the cycle of TDD. Write a test first. It will/should fail since there is no code which will make it work. Write code to make the test pass.  Refactor to make the code readable. Repeat the process till you complete the feature.  If you have observed a brick layer laying bricks. He will put little cement. Then he will lay the brick. Then he will adjust the brick to make sure it is laid right. This process is repeated till the wall is complete.  If you take the parallel to software development then you should make sure each line performs as it is intended in the overall feature. As a brick layer will not put a

W e were having a two-week sprint. We calculate the capacity of the team and reduce a factor based on previous sprint data. Then we come up with a capacity number based on which we plan. This should work fine. But we always had an end of sprint rush. Everyone will be working hard to complete the commitment. Last two days of the sprint is hectic with fixing bugs. Last minute fixes too require testing the full story. There is a high chance something slipping through the eyes. Even otherwise it should not be like this. We had the capacity and still some struggle to meet the sprint commitments. What is going wrong here? It is the bugs eating your capacity. When a developer completes a task it is handed over to the QA. Developer moves on to another item. This is normal scenario. Qa may not get onto testing the item immediately. It might be picked after a day. If the task is complete and works perfectly no issues. But if there is a bug then it is different dynamics. Turnaround of the task is