Its a general title for the question but I have a couple of questions for the Sprint in a SCRUM methodology.
-
What happens if a HOTFIX comes in the middle of a sprint. e.g – The website crashes or some part of the site that hasnt been worked on for quite some time crashes (like creditcard authorize or webservices etc). How do you incorporate that in the current Sprint(s)?
-
How to tackle bugs at the end of a Sprint. I know we can have Defect tracking sprint but should I plan for that at beginning? Or do I put that sprint back in the product backlog and start planning that from the next sprint planning.
-
How to decide how many sprints are required?
thank you for your help
Best Answer
Derrk,
1) All sprints can be halted at any time in reaction to things like the critical operational defects you mentioned. The reality is, no software development methodology would force you to ignore critical issues like an operational defect. If it did, it would never be implemented.
2) You can do this a couple of ways. As you mentioned, a defect-tracking sprint is one way of doing things. The reality is that under SCRUM you should always have a tester embedded into your team. Their responsibility is to create tests for each item on your work backlog. As items are completed, they should be immediately tested by your tester.
Now, in a modern agile environment this is usually done by your continuous integration environment. But normally, those environments don't do integration testing that well, which is where your tester comes in. AGain, remember, SCRUM teams are cross-functional, meaning they should include not only developers but also testers, CM, Requirements managers, etc. So, testing and defect tracking/correction will take place throughout your normal development sprints.
The testing sprint at the end of your development will be to validate the developed system works properly, prepare it for operational acceptance testing, deploy it into a operational test environment, excersize your system and then deployit into an operational environment.
3) Your Product Owner will be the one who determines that, and they will determine this by working with the customer as they prioritize thier product backlog. In reality, some business wonk will have signed the team up to deliver some sort of functionality by some fluid date range. The Product Owner will work with the customer to determine the degree to which that functionality should be implemented and exactly what should be included in each Sprint.
Of course, the Scrum Master and the development team will determine what they can actually develop during each Sprint and communicate this to the Product Owner. If the team provides feedback to the Product Owner that will result in a slip from the imposed time-line, it is the Product Owner's job to work with the customer to reprioritize the product backlog to take this into account.