How do handle adhoc work during a sprint from pressing customers

Question

I intend to introduce sprints to my company, fairly new to it myself. Not sure if it's appropriate for my current situation, we have several on going projects, all of them are ERP scale size and most of them I would say are nearing completion(Ready to deliver).

However during this time, there are a few customers whom we have no choice but set them as priorities so as bugs are still present hence if they discover issues with the system, they will contact us and we will have the team to sort it out asap. For now, this is the current practice. At such, if agile is introduced and we start using sprint, what can be done for add-hoc / urgent / pushy customers that requires almost immediate attention.

Problem is the company is lacking in manpower, only 3 devs in total and there's no dedicated testers around, hence till date, there will always be bugs lying around and customers will keep coming back. I understand that once a sprint starts, there shouldn't be any changes made to it.

Any advices?

Answer 1

There are different ways of tackling this:

• Zero-bug policy If you plan your sprint just with new features, but keep a zero-bug policy then your velocity will drop. Eventually you will know how much stories the team can get done while fixing any open and new bugs first. Understand Yesterdays Weather and plan accordingly.

• Placeholder PBI Each sprint add a story that counts as a placeholder for any bugs that come in. You reserve a fixed part of the sprint todo maintenance work. If it it takes up much more time, break up the sprint and start a new one.

• Assign a Batman: Read this answer to another question for details :)

• Shorter sprints If you have one week sprints and always put defects on the backlog, then the longest a client needs to wait is two weeks for a fix.

• Kanban Use kanban instead of sprints and focus on getting started work done, start working on high prio defects when picking up new work. Use INVEST to keep your tasks small, so that you can keep finishing work in small steps. Release all done work on a set date or release when you reach a certain point in your backlog.

For maintenance teams I would prefer Kanban, other wise use the zero-bug variant to get a realistic view on how much new work a team can get done.

Keep in mind you want developers to focus on their current task. Find a way to prevent bugging them during actual work with incoming defects. A daily stand-up would be a nice time to discuss new incoming work and re-arranging a sprint if needed.

Answer 2

This can be actively managed through some enterprising Kanban and a normal Scrum delivery team method. Some agile coaches struggle with the concept that an organisation can have a single Scrum Team delivering the business change from a portfolio of programmes with multiple projects all with their own 'backlog'. Sometimes Agile methods need adapted regardless of the guidelines. I humbly suggest the following solution.

It sounds to me like you are working in a business intelligence centre/role - am I wrong?

Preparation

Divide your sprint into two separate components.

• BAU Work (work outside the normal product backlog)
• Product Backlog Work (standard project work on behalf of the PM or Product Owner)

Decide how much of your sprint you are willing to sacrifice to BAU work. To help focus your delivery I suggest using the mantra

"people must be forced to make decisions."

You simply cannot deliver new change if business stakeholders continually want functionality repaired in the old system. Force people to make changes.

For this example I will suggest dedicating 20% of your fortnightly sprint capacity as BAU work.

Calculate your capacity of work per sprint in hours.

For this example we will use 3 x Full Time Resources coding for 7 hours per day for 8 days per sprint. A full day is devoted to planning and a full day to reviews and retrospectives.

That gives you an approximate capacity for 21 hours of work * 8 days = 168 hours of work capacity.

• 20% of that capacity is now earmarked for BAU work = 34 hours
• 80% of thatcapacity is now earmarked for Product work = 134 hours

Create a stack of user cards in a separate colour for the Kanban Board. These are your BAU cards. Give each of these cards a rough hours value adding to 34 and put them onto the board blank. For example: 1,1,1,1,1,2,2,2,2,3,3,5,10

Delivery

Use the cards to ensure you stick to your BAU budget. Any tasks that comes into the team is given a high level planning estimate in hours and the corresponding cards is then used to track the task.

If you run out of cards for that sprint you know you have exhausted your BAU capacity.

Report on the BAU workstreams as a separate delivery report tracking the amount of hours planned and accomplished for BAU tasks including the nature of the tasks and the RoI of the work completed.

Answer 3

With Scrum implementation, you will have a set of Stories with associated tasks to complete within a fixed time frame of approx. 2-3 weeks. Now, if anything new arises for the team to work on it should be prioritised for the next Sprint (assuming it can wait for this time). Otherwise someone has to make a priority call on it and whether the team should work on the new piece within the current stories. A stakeholder (PM) could move a lessor priority story for next Sprint, if that is possible. Otherwise all the stories should be completed within agreed time frame.

Alternatively you could set a Support process up between Development and the Customers (in they are not thousands of them) and allocate some of the team's time to it and work on these tasks in parallel with the assigned planned Sprint Stories.

Answer 4

Things can change within a Sprint if there is a good reason for them to change. Agile is all about value delivery. If you prevent meaningful change within a Sprint for the sake of strictly following Scrum guidelines you are no longer being Agile in your implementation of Scrum and you are reducing the value a customer gets from your services because of blindly following a process.

The scrum guideline to prevent story/priority/defect commitment changes within the sprint is there to protect the team from the majority of changes which are unnecessary changes introduced from knee-jerk reactions, the loudest person in the room syndrome, and poor iteration planning practices.

If a high priority defect (P0 or P1) arises within an iteration it is completely acceptable to defer story work if the fix is more valuable to the customer than the deferred work. You should always communicate the impact of deferring committed work to address a new priority. You have the PO on the scrum team throughout the iteration cycle to help the team continuously adapt to changing priorities as well as communicate to external stakeholders when changes occur. Many teams establish SLA's on around their defects to automatically dictate the time frame in which a certain type of defect should be resolved regardless of where in the iteration the team is.