Should we factor time in for UAT fixes & deployments as part of a sprint?

Question

We're a relatively small team and we are trying to implement an 'agile' scrum methodology around here for our projects.

All of our work is project based (i.e. we do not have a particular product that we are continually working on).

We've been planning our sprints around the user stories that we want to deliver for our clients, but we're finding that we're not effectively planning for rework that comes through during UAT (i.e. defects missed during testing, minor 'tweaks' requested by the customer) and for deployment to staging & production environments.

We can accurately estimate the deployments, but the rework is a real unknown for us. Does time for these activities have to be factored in as part of a sprint or does it just get treated as an overhead that occurs between development sprints?

Answer 1

In short, it is entirely up to you.

SCRUM

Both options you mention are valid, just pick the one that fits your team best.

If you spend a fairly predictable amount of time performing maintenance work, then just reduce the amount of time available for the sprint so that you have more 'overhead'.

If you find the the time cannot be predicted, make it part of the sprint backlog.

For what it's worth, I use Kanban now

I no longer use fixed-sprints because when I started to use SCRUM I quickly found that it was not assisting me. I now use Kanban with a workflow that I developed myself; my reasons for this were three-fold:

1. I found that organising work around use-cases tended to de-empahsise overall domain analysis and design (to the point of it not being part of the documented workflow at all).
2. Organising around use-cases (as you identify) does not suit bug fixes, revisions to spec/scope, or other miscellaneous pieces of work.
3. I find that I am better able to predict when I will have a particular feature ready rather than having an arbitrary sprint duration (usually two-weeks).

On my KanBan boards, my main work-items are functions rather than use-cases. These are defined by a domain-level analysis process that identifies use-cases, derives the functions from it and defines them as components.

I also have smaller work items that are linked back to their parent function, these are: Revisions (change in a function's scope), Defects (i.e. bugs or deviations from the stated function requirements), Oddities (minor changes that are not either of the others).

This gives me a good view of how much maintenance work I have to do in the next week or two and how much new development.

Answer 2

At one job, we used to roughly estimate how much rework we expected, based on previous sprint(s) and what items were just delivered. Then we'd time box it: set aside a fixed amount of time for UAT related, unplanned work and decrease the sprint capacity accordingly.

All UAT resulting stuff that wasn't explicitly planned was taken off the time box. No more time left in time box, no more unplanned UAT work.

With two week sprints this worked pretty well.

One caveat: you really need to keep track of how much of the time box has been eaten up and you really need to stop (unless hell freezes over) when all the time in the time box has been spent. That takes discipline and a good SCRUM master to manage outside expectations and priorities of incoming UAT work.

Answer 3

One of the things that all Agile methods, including Scrum, aim for is transparency. This also includes making it transparent how much work is going into stuff like deployments and bug fixing.

For doing/supporting the deployment, which has to be done every sprint, you could reduce the availability of the team with the time it takes to do the deployment. It might also be worth the effort to investigate how this burden can be reduced by automating things.

For the bug fixing, you should recognize 3 classes of bugs that need separate treatment.

1. Bugs found in the same sprint as where the story that introduced them is being worked on. These bugs should be fixed immediately, because technically the story isn't "done" while there are known issues. This might be waived for issues that would land low on the backlog if they were found later.
2. Bugs found after delivery that are important enough to require immediate attention. These bugs must be serious enough that the Product Owner is willing to cancel all ongoing work in order to fix that bug. Based on previous experience, you should reduce the availability of the team to create a buffer for handling these bugs without disturbing the sprint too much. If more bugs come in than the buffer allows, you should start dropping work from the sprint.
3. Bugs found after delivery, whose resolution can wait at least till the next sprint. These bugs should go on to the product backlog and be prioritized among the other backlog items. In the next sprints, you would then pull in a mix of bug fixes and new work.