Couple of questions about sprint in scrum methodology

Question

Its a general title for the question but I have a couple of questions for the Sprint in a SCRUM methodology.

1. 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)?

2. 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.

3. How to decide how many sprints are required?

thank you for your help

Answer 1

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.

Answer 2

1. In exceptional circumstances, sprints could be changed around to handle a major shift like a big production issue or if the company really wants some feature in ASAP that wasn't in the backlog previously. There are at least a couple of ways to handle this. First, there is the substitution of taking in the fix and moving out whatever the lowest priority committed item was in the sprint as there isn't room anymore for this. The other option is to cancel the rest of the sprint, plan a new sprint at this point and adjust future plans accordingly.

2. How critical are the bugs to the Product Owner? The Product Owner is the one setting the priority of items in the backlog and has a duty to make sure the backlog is up to date when the team plans their next sprint. There can also be cases where bugs are handled as part of a story if we are talking about bugs found while the sprint is happening compared to new issues found when a demonstration of functionality is done that could also be seen as bugs at the end of a Sprint.

3. How many for what? Realistically, there can be the never ending project as there will usually be new features, bugs found and other things to do so that one could just keep a team permanently assigned to that area. At the same time, any initial estimate on a number of sprints isn't likely to be accurate down the road when it may become clear just how much additional work is needed to finish what was originally asked.

Answer 3

1. You should treat emergency hotfixes like any other unexpected interruption in a sprint, e.g. someone being off ill. Make the fix, and then continue the sprint as normal. Your velocity will be lower for that sprint, but that's ok as it should disappear when averaged out over the long term. Of course, it may turn out that you typically lose a day of every sprint making 'hot fixes' so your average velocity will drop, but again this is ok, as it will allow for better estimation of milestones.

Answer 4

1) Fire fighting or zero point bug.
Fire fighting is where something is just so important that it has to be done now not matter what.
Zero-point bug is reserved for something that was implemented in this or the last sprint, has been claimed as done but subsequently found to be incorrect.
2) Zero point bug. If you claimed it as done and it isn't... you need to make it done. Put a card on the board as soon as you find the bug if it's urgent. If it's big and you can postpone it, it becomes a new story in the backlog to be prioritized along with every other outstanding story.
3) Decide how big an iteration is. Work out how much work you can get done in an iteration. How many times that delivers the whole product backlog?
This is an ongoing thing. You need to be working with a team on the same kind of work, using the same process and tools for a while before you have a stable, predictable velocity and can predict how many iterations it will take to complete the product backlog.