9

Let's say you have a bug on your website. Your developer needs to fix some CSS or something. He estimates it will take him one minute to fix.

What is the best way to manage these kinds of tasks? Do you create a User Story for it and create a task for it? The task is so tiny and minuscule that it's actually more work to create stories and tasks for it than to actually do it. This seems very inefficient, even though it's important to track and manage development of small fixes.

How do you best deal with small, one-off tasks that don't take long to accomplish?

Improve this question

8 Answers 8

Reset to default
8

TL;DR

Even when the change is apparently minor, it can have ramifications. The "one-minute fix" to some CSS class might impact the user interface (UI) on some other page the developer isn't thinking about, or might break important regression tests. This is the very definition of cowboy coding.

More importantly, bypassing the agreed-upon workflow is a recipe for lost productivity, allowing invisible work acting as a drag on the project and reducing overall product quality. "Just this once" creates technical debt, but a culture of "just this once" will eventually break your process. Don't allow that to happen.

No Invisible Work, Ever

Lets say you have a bug on your website. Your developer needs to fix some CSS or something. He estimates it will take him 1 minute to fix.

Your developer is wrong. It may or may not be as easy to fix as he thinks—developers have been known to underestimate tasks, especially if they aren't thinking about how "minor" changes might impact other things in the system—but any task carries real-world overhead such as:

  1. Task-switching overhead. Science tells us that interruptions often require an average of 23 minutes and 15 seconds for the task-performer to recover flow.

  2. Process overhead such as refactoring, unit testing, integration testing, and regression testing.

  3. Other process overhead related to your Definition of Done, including (but not limited to):

    • peer review

    • continuous integration (CI)

    • user-acceptance testing (UAT)

  4. Work-tracking overhead, which is essential to ensuring that there is no invisible work, ever.

Perhaps most importantly, unplanned work should never be added to the current Sprint. Some teams handle this by reserving capacity for unplanned work or by having a generic "minor bugs" story, but the best practice is to ensure that all non-critical bugs are prioritized by the Product Owner in a future Sprint.

Tiny stories might be assigned story-point sizes of 0 or 1/2, or they might be lumped together with other minor bugs. I'm a fan of lumping rather than zero-point stories, for the simple reason that no work is ever really "free" and the cost of a dozen zero-point stories is most definitely not zero.

If you use the lumping technique, your next Sprint might include "fix outstanding CSS bugs logged in Jira" as a Product Backlog Item (PBI) sized according to the number and complexity of the bugs and the related overhead of testing them. Unless cowboy coding is a project goal, even "minor" changes should go through the same development/testing pipeline as any other change to maintain product quality and avoid technical debt.

Improve this answer
1
  • Re: "Task-switching overhead" -- what about when the developer has already been interrupted? Ex: we have a Slack channel and prod errors get spat in there. I see a prod error & as such am already interrupted, and don't have enough info to diagnose the problem because the logging in that area of code is weak. I want to do a code change to add more robust logging. Now I have to file a ticket that is "add logging", get it estimated, have a conversation with the team to pull it in, do the change, go through deployment, etc all for what is literally a 1-line change that has extremely low risk?
    – Adam Parkin
    Commented Mar 7, 2018 at 22:38
7

Stuff like that should be in the working agreement of the team. There is no right answer on how to handle the situation but there are pros/cons of creating the story/defect and/or underlying task.

Pros: Creates visibility for the rest of the team Leaves an artifact that the work was done

Cons: Administrative overhead associated with creating/managing the artifact.

As a general rule of thumb:

The less mature the team is, the better it is to get them to create artifacts for all the work they do, whether its 5 minutes or 5 days. This helps create discipline and drive transparency as the team forms.

The more mature the team is the more acceptable it becomes to let pieces of work that are only a few minutes go under the radar. The team may have a working agreement that any work less than X minutes doesn't require a card. Mature teams should have the ability to communicate and retrospect on these items (if they start occurring frequently enough to warrant concern) without needing an artifact to reference in every instane.

So it really depends on the problems you are trying to solve with having the work explicitly tracked or not.

Improve this answer
4

Most teams I've worked with create a card and give them a size of 0, mostly for reference/logging purposes.

Improve this answer
0

I would create a card for it during the stand-up meeting and estimate it with the team. If its really 1 minute and it won't disturb the focus of the iteration do it, but don't disturb developers for it while they are working on something else. This also makes 'extra' work visible, this could be used later during the retrospective when Sprint goals are not met, certainly when its a lot of small changes.

If you have a lot of similar trivial changes I would group them into a somewhat larger one for the next iteration. Question yourself do we really need it now? Because what might look like a small change, can be somewhat bigger when the developer actually starts on it. Make sure its time-boxed and postponed if it does take longer.

Keep in mind that small changes could have enormous impact on other disciplines in the SDLC. Simple example could be that a lot of automated tests need updating, or translations need to be applied. Read more about impact of small 5 minute code changes at Microsoft: https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/

Improve this answer
2
  • How would you group lots of small tasks like this if they are all unrelated to each other? Like they have nothing to do with one another. They are all 5 minute tasks that do need to be accomplished though? Make a generic User Story called "General Tasks" or something? That doesn't seem right.
    – Jake Wilson
    Commented Jan 13, 2016 at 22:37
  • Not if they are not related, but I expected multiple small CSS bugs in this case. Maybe just put the cards close to each other. If you cannot give it a clear name then not group them. To be honest I rarely group issue's. Its not to much overhead going over a lot of small tasks during a planning session, because they are simple and easy to estimate.
    – Niels van Reijmersdal
    Commented Jan 14, 2016 at 8:25
0

Create a Ticket for it, gives visibility to the rest of the team and it also means it can go into the backlog - there is no guarantee that the developer who estimated it only taking a minute will fix that issue there and then - so there needs to be some record of it - otherwise it might get forgotten again.

it might then be a case of a team member picking up several of the tiny tickets at once

Improve this answer
0

I don't know if this helps but I manage agile and waterfall projects in my organisation. We deal with bugs separately. So if a bug is detected, it is raised in Inflectra Spira by the tester. It is not added back into the user story it is simply treated as a separate bug that needs to be fixed. All developers have some contingency built in to fix bugs. Bugs are part of the development and should not in my opinion be factored in as additional user stories in Scrum or Agile project management. Otherwise the project will overrun.

Improve this answer
0

Is visibility required by other disciplines/individuals?

  • If Yes - Create a ticket.
  • If No - Just do it.

Individuals and interactions over processes and tools

Keep it simple. Don't over solve a problem. Don't process for the sake of process.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.