How to handle arising tasks we want to address later in Scrum

Question

Considering we're talking about Scrum,

When working on a backlog item and that new out-of-scope minor tasks arise what do you do with them? (e.g.: ones we don't have time for right now such as minor refactoring or implementing tiny nice to haves)

Do I create orphan tasks to be later assigned to a backlog item with similar other tasks during the sprint planning meeting? Should I create a backlog item (requirement, or user story) with pretty much the same title as the task and assign the task to it?

E.g.: Let's say I create a new task which is "add a simple caption to a control". Should I promote it to a backlog items and in this case, what would be the task for that backlog item?

Thanks everyone!

Answer 1

I would start with the question "Is this necessary to fulfill the intent of the backlog item?"

Yes?

Some items are obviously a Yes. For example, if you discover that you need to add an option to a feature for the story to work properly, then obviously this needs to get wrapped in. However, there are less certain ones. For example, if in doing work you discover you really should do a refactor to move a method into a different class, this is a matter of technical quality and should also be included in the story.

You should never decide if something is part of a story or not based on how much time you have in a sprint. That leads to cutting corners and mounting technical debt.

No?

The easiest way to know that something is not part of the current backlog item is to describe how this new item builds on the existing functionality. For example, let's say I have a user story that I would like to be able to enter some record information for a website order. After looking at it, someone says "Filling out that form is confusing. I wish we had mouseover tooltips on each field." That adds some new capability to the feature and should probably be its own backlog item. Now, if you have time in the sprint and the PO agrees, you can bring that item into this sprint, but it's still really its own thing.

There can be grey area here, but adding in small things that aren't expressly needed because they're quick or easy leads us to gold-plating, which has a while set of other problems associated with it.

Answer 2

It depends on what the minor tasks are:

If they are related to quality, technical debt or a part of your team's definition of done

Do them as a part of the original story. If you take this work outside of the original story then you hide the true rate of progress of the team.

For example, a story appears to be done, but the reality is there is some technical debt that still needs to be completed. This can be misleading.

If they are improvements

Work out the value of the improvement (for example, the improvement will save 1 hour of effort per release in the future, or the improvement will make it easier to build upon the existing code).

If there is a decent value to the improvement, add it as an item to your backlog. Backlog items don't all have to be user stories, there is nothing wrong with adding a task to the backlog.

If they are nice-to-have, but of little value

Consider dropping them. There will always be more valuable things to work on, so there is no point cluttering up the backlog with things that generate no real value.

Answer 3

If these out of scope tasks are related to code quality do not create new user story or tasks for them, just do them, because they are part of "better quality" aspect of scrum. If you start to write separate tasks or user stories for these, they will be the first to drop when the end of sprint is getting closer. Make a habit of doing these when you work on the tasks.

Nice to haves and others should go to the backlog as a user story (some call them developer or technical user story), and the PO shall decide whether to do them or not. If you have a good business case backing them, you have better chance to have them in your next sprint backlog.

Answer 4

We do include them immediately into the current sprint. Scrum doesn't force you to plan your every move at the beginning of the sprint. As you can see in this Collabnet video this is allowed in Scrum.

Check out this PM discussion on the subject.