Scrum for very shot "bug-fixes" ?

In example a bug-fix to the project made above with the scrum framework. In these cases, how do you handle the work

Projects aren't bug-fixed, products are:

• The Definition of Done must be improved to truly reflect what usable means and to prevent defect recurrence.
• The Product Backlog must tell the truth at all times about how much work remains for the product, including any technical debt such as defects.
• A Scrum Team may then adopt a policy of remediating a certain amount of that technical debt each Sprint. Losses due to any context switching ought to be taken into account.

Bugs are things that need to be corrected in order to improve the Product.  Features are things that need to be created in order to improve the Product.  The Product Backlog is a list of all work needed in order to improve the Product.  The Sprint Backlog is a selection of items from the Product Backlog that the Developers feel can be done in a single Sprint that will also satisfy the Sprint Goal and increase the value of the Product to the stakeholders.

I am not sure why people always think that bugs are something special and need to be handled differently.  In my past I have worked as a developer.  I have had bugs that took me days to correct.  I have also had features that took me half a day to implement.  I suggest to people that they should stop looking at the "type" of work being requested and look at the "value" that work provides.  Treat everything equally. Don't call them bugs and features.  Call them items.  Focus on doing the items that will provide the most value to the product.  There are times that fixing a small issue could have more value to the 1,000,000 users that introducing a new feature.  There are also times that finishing a new feature provides more value than addressing incorrect behavior. 

I would say that Scrum is a journey to product goal where a sprint goal is created for each sprint.

So, if your sprints have a clear goal and the PBI (let's not say "bug" for now) that are selected in the sprint will allow the team to achieve that goal and create useful increment, then there shouldn't be anything special for your case.

However, if this is not your case, I think Kanban flow may be more suitable for your situation.

I agree with you, but there are some situation where a single developer is more than enough to "fix" something. Stupid example: a typo on a website. The task "fix the typo on page X" is created and goes to the backlog, but we can't wait up to the next sprint to fix it and also we can't do a brand-new sprint (with meeting, daily scrump and everything else) for a 30-seconds task like fixing a typo that need to be fixed and released immediatly regardless the status of the sprint.

We have many, many project that are "live"/"in production".

Sometimes on these project we need to add one ore more features.

For these features we create Sprints and we'll work as expected (sprint meeting, daily scrum, sprint retrospective, ...). But, at the same time, a typo to fix has an higher priority, it should be addresses ASAP and can't be placed inside the running sprint (if any, because some project are just in production with no works planned/running on them, so there isn't any sprint/backlog/whatever related to the project)

It sounds as if you are aligning Scrum Teams with projects rather than products, which is fine, but if you aligned a team with a Product then it could be added to their current Product Backlog and addressed in the Sprint.

I wouldn't spin up a Sprint to fix a bug from a prior project that has closed, there's too much overhead for that.

If the team is working on a Product, if the Product Owner feels like it is a priority to fix the typo immediately, they can have a conversation with the Developers about pulling it into the current Sprint if the Developers agree they can get it done without interfering with the Sprint Goal. And if you have empirical data that suggests there's a certain amount of these bugs that need to get addressed, the Developers can build that buffer into their capacity during Sprint Planning.

if any, because some project are just in production with no works planned/running on them, so there isn't any sprint/backlog/whatever related to the project

As @Chris said, typically Scrum is expected to be organized around Products not projects.  It sounds like you are trying to use it as a project management tool where each Sprint is for a different project.  Scrum is used for incrementally delivering updates to products so that feedback can be received to influence the next set of updates.  The work is constantly evolving as new information is received and that work is represented in the Product Backlog.  A Sprint is a container to deliver work that supports the Sprint Goal. That work is pulled from the Product Backlog into a Sprint Backlog.  The Sprint Goal could be to deliver a new feature or it could be to make incremental progress towards a new feature. 

There is nothing that states that all of the work done during a Sprint has to be related to the Sprint Goal. Just that the purpose of the Sprint is to achieve the Sprint Goal above any other work.  In the teams I have worked with it is quite common for the developers to have some small items that are unrelated to the Sprint Goal, such as fixing a typo on a web page.  That is work that improves the product, needs to be done, and adds value.  

If you have some "projects" in production, in Scrum terms you have a Product.  There has been some work done on it in the past, it is still in use, stakeholders are still receiving value, and there could be future work needed to improve it.  So that is where the Product Backlog comes into play.  As long as a Product exists, there will be a Product Backlog.

I have never worked with a team where there was a single code branch in use for a Sprint.  Typically there are multiple branches in use, merges that occur, and even multiple pushes of code to production.  CI/CD is very common today and Scrum works really well with it. 

a typo to fix has an higher priority, it should be addresses ASAP and can't be placed inside the running sprint (if any, because some project are just in production with no works planned/running on them, so there isn't any sprint/backlog/whatever related to the project)

Projects aren't in production, products are.

It sounds like your product may be a service (within which multiple products are serviced). If so that's fine. It can be a complex challenge to provide service level expectations, and worth using Scrum under such conditions. A backlog may then be triaged to ensure a Sprint Goal for a given SLE is met.

In every case however, the Definition of Done for the relevant product would have to be improved to stop defect recurrence. That improvement to a DoD would then be a condition of Done for the overall service being provided.

thank you all.

sorry for the wrong terms,as i'm new to Scrum. I was referring to a product, not a project.

As some of you alredy noted, starting a sprint for very short task would be a huge overhead, if the product was already closed.

As wrote previously, let's assume, as an example, a product called "website creation".

You have some product backlogs, some sprint backlogs, some sprints and so on....

Then, at one point, the product is finished and the website published. We don't have any more items in the backlogs (or the remaining ones are deleted because not needed anymore, or simply left stale, as the customers doesn't need them, the website is already published!)

Suddenly, after X time (a week ? a months ? a year?) a bug is detected. The fix is simple, because it's a trivial task: just replace a single lowercase "i" with uppercase "I" in the homepage.

Product owner, that talked to the customer, open a task in the product backlog, setting it as high priority.

Ok, now ? Starting a sprint, with planning, daily scrum, retrospective and so on would be a HUGE and useless overhead in this trivial task. One, from the developer team, could pick the task and directly fix it bypassing the full Scrum scaffolding ? Not more than 4 minutes of work.

And what if the task (bug-fix , feature, it doesnt matter) required more than a couple of minutes but still much less than a standard scrum workflow ?

Except for the project starting phase, that could least many weeks from the initial meeting with the customer to the publishing, we have A LOT (90% of our works) of many small/short tasks that requires, on average, less than half day to complete. we have a lot of these. 3 hours in this project, 2 hours on the other one and so on. Starting a sprint for each of these tasks means to spend more time in meetings than in development. And sprints would be 4-5 hours max. Would you do a retrospective for a 4 hours job ?

This is not clear to me.

Any real example on how to adopt Scrum for a web agency/software house with huge products to develop and the daily maintenance routing like fixing bugs on completed projects ? (if a sprint is still running, the "short task" is added to the sprint and addresses immediatly)

We are a small team (4 "developers" including me (the company owner and lead developer, in scrum probably i'll be the scrum master too as i'm trying to adopt scrum, the graphics designers, and the copywriters), we'll form a scrum team with the Product Owner set as the sales person that talks to the customer and will be our interface between our (the developers) and the customer.

Scrum defines a product as…

a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

What is your product? Does it have clear boundaries and known stakeholders/customers?

You mentioned...

a product called "website creation".

Is your product a service that creates websites or software for others? If so, that service could be your product, not this one website you are producing. If “website creation” is going to take a number of Sprints, it might be your current Product Goal to plan Sprints against.

You also mentioned…

You have some product backlogs, some sprint backlogs, some sprints and so on….

If you have one product, you have one product backlog in Scrum (with one product owner). “Some product backlogs” would require some product owners (one for each).

“Some sprint backlogs, some sprints” would require some Scrum Teams (one team for each product).

It doesn't seem like this is your situation. Seems like you have one team. To leverage Scrum, you should have one Product, one Product Backlog, one Product Owner and one focused Sprint and Sprint Backlog per single Sprint.

As others have mentioned, Sprints are not started up for a single job or task. Sprints run on a regular cadence of 1 month or less. Say you use 2 week Sprints. Every 2 weeks a new Sprint begins. It is like a train going around a track picking up new Sprint Goals/objectives each iteration. That train travels around the same Scrum Event loop (Sprint Planning, Daily Scrum(s), Sprint Review, Retrospective) every 2 weeks non-stop until you no longer have a product.

Keep in mind that english is not my primary language so probably i'm mixing some terms.

The website creation is the product. We have to develop a website for a customer. (not a software that creates websites)

We have multiple customers, with multiple websites to create.

Each website is a product.

As we are a small company, all products are "assigned" to the same team (the product owner could be different, as we have multiple sales persons), but the developers team is always the same.

Let's start from scratch with a real example: a customers open the office door, talkt to the sales person and ask for a new website. The sales person (the future product owner) ask some questions to the customers, do it's works then, at the end, it start a new product, with a new product backlog and start to add one or more stories based on the customer request.

The day after, a new customer comes, talk to the same salesperson (the colleague is on vacation) for some marketing (advertising on google, on paper, on tv, and so on). Same as the other product: a new product is created, a new product backlog is created and filled with one or more stories, but in this particular case, there is just one person involved from the developers team, because the other doesn't have the knowledge to do this kind of works.

Up to this, it should be correct. What we should do to go further ? There are two different project, with different stories and different goals.

@Gandalf TheGrey You have raised very interesting quetsion, which was actually hunting Scrum, creating "Scrum vs DevOps" issue, until 2020 update of Scrum Guide hasnt integrated Scum with DevOps and XP practices, particularly in QA(testing).

In a nutshell, "fixing" bugs is a part of developers work within a Sprint, just like any other task they pull from the Porduct backlog. In the ideal Scrum environment the Scrum team should have one bug per report, and PO should agree to have those reports present at the Product Backlog-unless Product backlog is open for everyone to update, like I suggested in my recent suggestions for a Scrum guide .

During the retrospective Scrum team may decide to include "fixing bugs" as a PBI in Product backlog. After that Developers can make it a task for upcoming Sprint in the subsequent Sprint planning.

Having said that, it is worth mentioning that bugs are often a result of "technical debt", xhich is an  imperfection of the product(code) caused by various external factors(deadlines, overcommitting, stress, speed etc).

Having established DevOps cadence and metrics, and QA techniques like TTD(test driven development), and CI/CD within a Sprint may help reduce bugs.

Particularly: making sprints as short as possible, making tasks(PBI) as small as possible and having automated release of very small increments often, during the course of spreet, sometimes with even the daily feedback loops. Big number of releases increases "time to the market" - important KVA which an element of Evidence Based Management, but its another issue.

Thank Nicholas but this doesn't answer the question: how to handle very short tasks and daily routines if no sprints are running (the product was delivered and completed). Using the full Scrum workflow would be a huge waste of time with a huge (and useless in this case) overhead.

You would start a sprint (and it meetings) for a 1 hour task that would be fullfilled by a single developer anyway ?

Can someone post some real-world usecases and workflow for a webagency/softwarehouse to better understand the scrum framework ?

Scrum is not the solution for every company.  It is a framework created to help with complex work that requires the ability to adapt quickly to change as it occurs while delivering iterative advancements towards the ultimate goal.  From what you have described, I don't think your work fits that pattern.  Your work seems to be fairly well defined upfront.  You might want to consider looking into Kanban instead of Scrum. If I were working at your company, that is the path I would advocate.  In my experience it works better for multiple concurrent projects with a single team of developers.  And it also can accommodate "one-off" work much easier than Scrum.  I have used it in a situation where we had one development team that worked on multiple products at a company that published books (yeah, those still exist).  It worked well for us and allowed us to advance work on multiple projects while giving full visibility to people outside the team. Look me up on LinkedIn and I can share some examples of my Kanban experience if you are interested. 

Now, you wanted real-world examples.  I have never worked for a company that does the type of work that you are doing.  All of my experience has been with companies that create software products that are sold to others or used internally to run their own business.  I could come up with a theoretical example. But I would not be able to support it with actual evidence. Maybe someone else can provide you with those examples. However, as I stated above, there may not be any good examples because the work does not seem like a good fit for the Scrum framework. 

Thank you Daniel, I'll contact you shorty via linked-in (with my real account obviously)

Yes, probably Scrum doesn't fit very well in our development workflow, at least not for the most type of works, pretty standardized during the years. I'll give a look to kanban, do you have some docs to suggest ?

But for other developments, like our internal project, that never ends (we always add something new or refactor something old), scrum could be valid and is much easier to implement for our internal projects (ie: a very short task can be easily added to the next sprint, becase we'll always have a pending sprint in our projects, not like customers project were, after delivering the website, probably we don't touch it for years, simply, we don't have a pending sprint for some customers)