According to scrum, how do you handle troubleshooting problems in an application as a developer?

Question

Maybe if I give a couple of examples it will explain my question better. I am a Lead Developer and I've noticed that frequently it's difficult to estimate the amount of time troubleshooting and resolving a problem on an application will take. Frequently, we think an application error is being caused by one thing but then you start working on it and it becomes evident that it's likely something else that is much more complicated to resolve. It probably doesn't help that many of our developers are on multiple sprints so switching gears is not so easy.

I will give another example that might help explain the predicament better. Let's say you take your car to the auto shop because your a/c is broken and while they're trying to fix the a/c, they discover that it's not working because of a serious electrical problem that's actually much more complicated and need to keep your car for much longer than initially anticipated.

What do you do in these situations? Do you update the story/tasks mid sprint to more accurately reflect what it is that you are doing? Do you keep working and update things after the fact? Or maybe there's some other technique I'm not familiar with? I'm no scrum master but I've been a developer for many years and I know this problem is quite common.

Answer 1

Regardless of what approach you use to forecast your performance, there are tasks which are inherently hard to estimate. Finding and fixing bugs are among the hardest.

You need to either allocate some reserve capacity for dealing with this kind of tasks (and don't funnel them through an estimation-driven process), or you accept that the difference between estimated and actual time needed may influence your measured velocity and thus future sprint planning.

I'm inclined to leave impossible-to-estimate work out of a process that is designed to optimize flow, unless you encounter such situations regularly enough so considering their effects on velocity makes sense in the long run.

Answer 2

In Scrum, the representation of the current work is the Sprint Backlog. In the Scrum Guide, the Sprint Backlog is described as "a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal" and that it "is updated throughout the Sprint as more is learned".

Since Scrum takes a minimalistic approach, any further details on how work is represented in the Sprint Backlog are left up to the Developers, perhaps with guidance coaching from the team's Scrum Master.

Since Scrum supports the values and principles of Agile Software Development, it would also support welcoming changing requirements. During the course of their work, the Developers may discover new work that was previously unknown but not necessary to achieve the Sprint Goal or complete Product Backlog Items selected for the Sprint. This work could be added to the Product Backlog for ordering, refinement, and selection in the future Sprint.

There's no one-size-fits-all approach. If the stakeholders can look at the Sprint Backlog and get an understanding of what the Developers are doing to work toward the Sprint Goal, the requirements of the Sprint Backlog have been fulfilled. If the stakeholders do not have the necessarily visibility into the work or are not able to get the information that they need, the Developers (with the Scrum Master) can work with the stakeholders to help them understand Agile Software Development, the Scrum framework, and find ways to have the necessary information at the right time.

As an aside, I'll add that if "developers are on multiple sprints", you're probably not doing Scrum. Even setting Scrum aside, this lack of focus on a singular, cohesive goal is often detrimental to achieving agility.

What do you do in these situations? Do you update the story/tasks mid sprint to more accurately reflect what it is that you are doing? Do you keep working and update things after the fact? Or maybe there's some other technique I'm not familiar with? I'm no scrum master but I've been a developer for many years and I know this problem is quite common.

Answer 3

Ironically because the situation describe is quite common, it is less of a problem.

When you measure your team's velocity it will be impacted by the discovery of new work that is not anticipated. This will mean that the amount of work you put in to future sprints will be reduced.

For example:

We put 20 story points in the sprint, but a couple of the stories proved to be a lot bigger than expected and so we only got 15 story points done. Our velocity dropped, so we will add fewer story points to our next sprint.

In effect, the team's capacity to do work will often be more than the amount of work they add to a sprint. The discovery of work as the sprint happens expands to fill the difference.