In the old day’s changes to project scope were unloved. They either increased the time to deliver the project or increased costs or more likely both, and that was bad. Change control processes were brought in which were promoted as a positive method to manage the impact of change on a project but instead were promptly re-purposed to inhibit changes to scope. This made project managers happy, the project was delivered to specification, on time and on budget. But the customer was sad as the product they got was no longer what they wanted.
Does this exist in Agile projects?
Changes of scope are good; they are just a question of priority. Changes to scope may involve new requirements discovered through the regular feedback loop baked into Agile frameworks. There may be emerging work discovered when delivering a piece of functionality is more difficult than first thought. Focusing on the immediate work means that requirements will emerge as work further down the backlog is eventually elaborated. In an Agile team capacity is constant. This means the team can deliver a fixed amount of work in a fixed time. As new high priority requirements emerge it simply means that lower priority work will be delivered later or not at all.
Sometimes organisations buy capacity and they have fixed business priorities. New requirement and emerging work set against a backdrop of a fixed capacity still creates that uneasy feeling in some stakeholders when they realise their commitments might not be met and often results in them reaching for the old scope management techniques.
Scrum gives us some approaches to deal with new requirements and emerging work.
When delivering a story, emerging work is unpredicted work that is required to get the story done. This is just the effort required to complete the story, whether it was predicted on not. This gets revealed in the team’s velocity and by definition it is reflected in the work the team forecast that they can achieve in the next sprint. Forecast too little and more stories can be pulled into the sprint. Some teams use tasks to provide visibility of the work they are doing. When work emerges they add new tasks. Adding tasks is absolutely not something that should be avoided. Adding a task to a story in a sprint is not scope creep.
Sometimes the feedback loops build into Agile frameworks uncover new requirements. Ideally a new requirement is a new story. It should not be rolled into the existing story. There are many reasons for this but the one that always comes into my mind is related to the new story’s priority. It would be wrong to assume that the new story has the same priority as the original. It might be low so it can wait until a later sprint. It may be higher so the team need to refocus their efforts on the new priority.
If the PO can’t wait for the next sprint, the work can be added to the current one. Again it is a question of priority. The team’s capacity is fixed. Adding more work means the lower priority work falls out of the sprint and into the product backlog. In Scrum the sprint goal is used as a yard stick to determine whether the story goes into the sprint. If it supports the sprint goal it can go in, if not other options should be considered.
If the nature of the story and its priority means that the sprint goal is no longer valid, the PO has the nuclear option of abandoning the sprint. This needs to be carefully considered. Doing this has an overhead because the team must regroup and re-plan. It can be very upsetting to a highly performing team if their cadence is disrupted like this. If feedback loops are short, then the time to wait for the team to get to the new work should never be that long, which reduces the chances of needing to abandon the sprint. If feedback loops are longer and requirements are volatile, then the risk is increased.
It is probably worth highlighting an anti-pattern at this point. Agile by its nature embraces change. However constant change is disruptive. I see the current sprint as the calm in this storm. It is the place where the team can focus and get on with the work in hand. However, if the sprint itself is not held in high regard and disruptive change is allowed to creep in, then the fundamental benefits of Agile can be lost. When stories keep changing within a sprint or the sprints are constantly re-planned a churn is created which means the team cannot accomplish anything…, but at least they were being Agile.
Is this what scope creep looks like on an Agile project?
The best user stories are unambiguous. It should not be possible for there to be multiple interpretations of the story, its description or acceptance criteria. However creating an unambiguous story is hard,… very hard. I am yet to see it done consistently across a project. It is the team’s responsibility to create an unambiguous story. Whether this is done as part of sprint planning or in a story kick off is up to the team. When an ambiguous story gets into the team this could cause a problem.
A highly performing team is motivated to complete work. They will have delivered the work based on their interpretation. When the time comes to agreed that the story is done, other stakeholders may have a different interpretation and the team cannot close the story. The story isn’t done, it cannot be released and the team cannot get working on other stories. I have witnessed situations where a small ambiguity in a story is used to lever open the scope, making the story much bigger. The team are then held to account over why it is taking so long to deliver it. The result is a never ending story that is carried forward across many sprints. The team feel that they aren’t accomplishing anything and moral drops through the floor.
Maybe this is what scope creep looks like on an Agile project.