Best practice to register additional tasks

Question

I am relatively new to the Scrum way of working and was wondering what to do with small tasks. Besides the main User Stories, we always end up with additional requirements or small changes after the main User Stories are 'finished', e.g.:

• Change the title of the application
• The font of the main page should be bigger
• Removed column X in table Y

Currently, our Project Manager creates one big "User Story" for these and copy/pastes all these small tasks into it. What is the best practice for handling these kind of tasks?

Answer 1

The dev team can add small tasks needed to accomplish the Sprint Goal to the Sprint Backlog

Here is what the Scrum Guide has to say on this topic:

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.

If these small tasks are needed to accomplish the Sprint Goal, the dev team can add either sub-tasks or separate stories to the Sprint Backlog and complete them during the sprint.

However, if they are not strictly required to accomplish the Sprint Goal or new larger stories are discovered, write them up as separate stories and park them in the Product Backlog for the PO to prioritize.

Answer 2

I've never been fond of the 'all-in-one' approach. What if, a year later, that small change is found to somehow have major ramifications? You trace the code back to the Story and... it's clumped together with a bunch of others.

What I've done is create each requirement into its own Story. Not necessarily each task - each Story should, by itself, provide business value. My Team then assigned a story point value of 0.1 to the Story. We used this number for anything estimated to take less than an hour.

Answer 3

In general, you can reduce the occurrence of such late feedback by encouraging early and often review of material work-in-progress by using a live staging environment, e.g., an area where your PO can go each day to review any upcoming stories. If your PO is only looking once a sprint, that's a problem that you all need to address, what if the issue was something bigger than just the font type or page title? Try to get your developers and your PO (and business analysts) talking, reviewing, and collaborating everyday.

Answer 4

Once the task is done according to its description, the task is done. If the description changes because the requirements weren't right... that's another task (it can be a subtask or a related/linked task) that have to be measured as any new task.

When the task is In Progress or Created (and estimated): if the change is small, I add it... if the change is big, it's a new task. We finish Task #1 and once the Sprint is done, we will measure Task #101, with the rest of new tasks.