From 'Sneaking in' to Scoping In: How to Handle Discovered Improvements

It came up in the weekly team leads meeting recently that it's not always clear to team members how to get time to work on things they discover and think need to be done.

The scenario is that you are working on some story and notice something that you think should change or that you're enthusiastic about working on. For example, there's a class you're using that, if refactored would make your work, and future work, easier or faster. Or maybe part of the build is being frustrating and you think you could improve it. Something like that.

The idea that it is normal or necessary to "sneak in" such work was mentioned. Sneaking things in by doing them without communicating that you're doing them is not working in good faith.

I want to share one way work like this can be done in good faith. At least this is one way that has worked in the past between me and my team lead.

I'd go to the team lead and start a discussion like:

Me: Hey, I'm working on and noticed . Can we expand the scope of the story to include that work?

Lead: Good thinking, what does that work get us, and how much additional effort do you think it'll take to pull off?

Me: By doing this work now, we benefit because . I'd say it's additional points of effort.

The important part is that I have context on the value of the change and my enthusiasm for the work, and the lead has context about the current needs and goings-on within the company overall. So from here, there's a few different ways the conversation could go. Here are some examples of how it might play out from here. These examples aren't intended to be comprehensive, but to give an idea of some directions that the conversation can be productive in.

Lead: That seems like a good inclusion in the current sprint. Let's scope it into the story, go ahead and update the story points in Jira to reflect the new scope.

Lead: We're tight on bandwidth this sprint. Scoping this in would mean pushing out of the sprint.

Lead: We've got coming up and our users are depending on us to hit it. There aren't any stories that make sense to push out of the sprint in light of that. We'll make a new story in Jira. Where do you think it should land in our backlog compared to the other work we're trying to accomplish?

Lead: That does seem valuable and timely, but it's too unrelated to your current story and will complicate the review too much. We can do it this sprint, but let's make it a separate story. Do you think its immediate value to your work is high enough that we should do it before continuing on your current story, or can we finish out your story before starting work on this new thing?

As a developer doing work in our codebase, you have a lot of context on where there's friction and where high impact improvements can be made. Your insight is critical to the continued efficient operation of the company and we want to learn from that insight so we can do better!

That's not to say this approach is simple. Indeed, there's a number of ways this can go wrong that are worth addressing. Some of these are problems of communication and are addressed by taking a step back and talking about them, retro is a great place for such discussion! Some of these problems are problems of judgement and are improved by experience and practice, and on the flipside, if you don't practice this, you won't get better. Being wrong sometimes is part of learning and is to be expected! It's always going to feel slow and awkward to work through this process to begin with, but so long as the team lead and the team member are acting in good faith, it will improve with time and practice. Like any communication skill, this gets better with deliberate practice - both developers getting better at articulating value and leads getting better at rapid priority assessment and communicating appreciation for the insight. Help and support one another at improving!