My development team is not fully isolated from maintenance. We use Scrum with 1 week sprints. The backlog for a given week is composed of development and maintenance (bug fixing) tasks.

Some of our clients are entitled to prioritized support. We do have a separate support team but our development team contains experts in certain areas. Our boss sometimes asks us to change the scope of a given sprint to accomodate prioritized support tasks. In general the scope changes are minimal and the team understands why this has to be done.

Things get a bit trickier when a client is doing UATs and is very close to going live. Sometimes we're asked to prioritize a support task "immediately", obviously causing waste and frustration in the DEV team.

From my point of view, when facing the situation above, I'd rather fallback to 1day sprints until the client goes live and we can resume our regular 1 week sprints.

This would avoid wasting time on an extensive weekly Planning Meeting that has a high chance of not reflecting the real scope of tasks predicted for the upcoming week. I'd have daily plannings combined with stand-up meetings.

What do you guys advise?

  • 1
    See: sites.google.com/a/scrumplop.org/published-patterns/… Commented Jan 16, 2016 at 15:35
  • Great comment, Jesse! That gives me a pretty good argument for negotiations with Business and the team. So I take it that the answer to the question is "No, 1 day sprints make no sense" and the "limited resource situation" should just be made visible to all counterparts and proper planning done around it.
    – Joao Silva
    Commented Jan 16, 2016 at 21:00
  • I see. The cause for the interruptions are very clear and rather unavoidable - an important client changing requirements or finding bugs next to GOLive. Business knows this causes waste and frustration on the DEV team and is OK with moving the deadlines for DEV releases due to this. The question is what approach to use in such case when we rather expect drastic scope changes during a (for instance 1 week) sprint. Allocate a buffer based on a guesstimate or rather temporarily decrease the sprint durations (for instance to 1 day) until the situation gets stable (the client goes live).
    – Joao Silva
    Commented Jan 16, 2016 at 21:16
  • Alright, I guess the discussion has somewhat drifted away from the main question into "how to avoid getting into a given situation". Using a medical metaphor, if a team of nurses started the night shift and planned helping 10 disabled patients bathe, have supper, take their meds, etc (planned scope) and got a call from the head doctor that an ambulance has arrived and they should help by an amputation (prioritized client) there's no trying to figure out how to avoid this situation, but deal with it in the most efficient way given the circumstances.
    – Joao Silva
    Commented Jan 16, 2016 at 22:38
  • The head doc (Business) is fully aware that the patients will get bathed and have supper later. Should the nurses still go ahead and plan their entire 12h shift knowing they'll most probably change the scope (since they heard on the radio that a huge traffic accident has occurred at the corner of the hospital)?
    – Joao Silva
    Commented Jan 16, 2016 at 22:41

4 Answers 4


I don't think 1 day sprints are your solution. You have support requests that are of greater importance to the client coming in mid sprint. Sometimes your team has to drop everything and release a patch.

Here are two approaches I would suggest. These approaches make different assumptions about the size and consistent nature of the support work, and can be combined as appropriate.

1 : Treat support as a background task.

Not everything needs to be be put on the board and estimated, there are many tasks like continuous improvement, exploratory testing etc that form a background of work that needs to be done. Count support as this. The velocity of your team will reduce in accordance with the amount of support work you do, and you can plan new work on the basis of that lower velocity.

This strategy is best if support is fairly consistent. It also has to be clear to stakeholders that velocity is planning tool, not a performance metric, and it's reduction here is not a problem.

2: Drop work off the Sprint to fit in support tasks/ deliver a 'best effort' sprint in the case of an emergency

It's perfectly acceptable for the PO and Dev Team to trade work in the current sprint for more important things if business priorities change.

However appreciate that you won't want to take time to estimate 'emergencies' just to make a decision of what to drop. An alternative is effectively dropping the entire sprint, and then after the emergency is resolved, figure out what 'best effort' to finish as many of the sprint items as possible.

Any option that involves dropping work off the sprint, incidentally, is much easier if you minimise work in progress. It is also worth making sure during sprint planning that you always do have stories of roughly emergency size that can be individually dropped.

  • This is how I've done it too, figuring out the consistency of support will involve tracking and estimating it's velocity over time, but once that's done, it can efforted for imperfectly, but reasonably.
    – RandomUs1r
    Commented Jun 20, 2018 at 19:41

Let me first answer your main question, "Do one day sprints make sense". In general: no. The need for a one day sprint are often a sign of things out of control. I've seen agile coaches practice one day sprints in operations environments and in crisis teams, but never for software development teams who also need to deliver features.

Scrum applies Focus to ensure that the value delivered in a sprint can be maximized. Interruptions and massive scope changes, as well as loads of defects and incidents cause the Focus to be lost and will drastically lower productivity, the ability to estimate and to create a short term plan that helps you achieve your sprint goal.

Often the notion of one day sprints are caused by problems in previous sprints, Product Backlog Items declared done, receiving massive feedback from clients when shown weeks later. That's a sign of the customer not being involved often and early. It's also often a sign of an absent product owner or a proxy product owner.

It may be that the nature of the work is just too unpredictable, in Operations environments or customer support departments, you often see that the flow of incoming work is constant, yet the ability to predict the work coming in is absent. In these cases Kanban or another flow optimization technique may be better suited than Scrum. It's not valuable to spend half a day planning, knowing it's for naught. You will loose some of the benefits of continuous learning, cadence and predictability which Scrum offers, and will need to ensure you either keep doing some of the Scrum events or do something else instead for your Sprint review an Retrospective.

It sounds like the nature of your work should not be the above. You can cater for some incoming additional work using a small buffer or some up-front discussion with the product owner about which PBI's carry more value than others, so you know how to deprioritize some work over other. A strong product owner can also help in these cases, weighing which issues are truly worth interrupting the team for and which ones need to be pushed back to the client. Each incident gives them a short burst of value, but it tends to lower the long term value due to the fact that you're unable to deliver new items in a sustainable way

It also sounds like your Support team could be a better buffer for the Development team. Would it be possible to rotate some Devteam members through the support team for a couple of weeks/months, pair-programming with the support team? That would allow the support team to pick up more knowledge of the products you're building. That way they can solve more issues themselves.

It also sounds like the customer isn't always happy with the work delivered, or has new insights based on what they see, can they be involved earlier and more often than you're doing now?

You may need shortish sprints, say one week, due to the fact that part of your work is unpredictable, but with a strong product owner and the ability to deliver new work mid-sprint (by not waiting for acceptance at the end of the sprint), you will be able to either postpone some of the work to the start of the next sprint, or to keep a buffer to deliver the highest priority work this sprint.

Just a final note: Your team is the owner of the Sprint Backlog and is allowed to ignore or refuse requests to change the sprint backlog. They're required to when the Sprint Goal is jeopardized. Only when the current sprint goal is no longer valid or valuable, is the Product Owner allowed to cancel a sprint.

  • Again a drift away from the main topic... Look at the previous answer for a proper (and concise) one.
    – Joao Silva
    Commented Jan 17, 2016 at 19:02
  • The other answer works around the problem, but doesn't attempt to address it. Scrum makes your problems transparent, as you've found out,buy doesn't solve them. Commented Jan 17, 2016 at 19:04
  • Then you didn't get the problem, mate. It's not how to predict and avoid a situation, it's how to deal with an unpredicted situation...
    – Joao Silva
    Commented Jan 17, 2016 at 19:06
  • If that unpredictability is to such a level that it keeps breaking your focus, frustrates your team and make you fail your sprint goal, there's a bigger thing to fix. Commented Jan 17, 2016 at 19:24
  • No more comments from my side, mate...
    – Joao Silva
    Commented Jan 17, 2016 at 20:23

Why using sprints for support anyway? Use kanban board instead, with priorities in rows, that will do the trick. You will always have ready for development row prioritized by customer. Developers should just take any top prio task. If you are using some CI and DevOps automation you can release everytime you have a task or group of tasks done, even every day.

So my solution here is SCRUM for development, Kanban for maintenance.

I have also used one day sprints for one man project but this is exception.


Kanban seems much better suited to what you're doing.

You can call it 1 day Scrum sprints if your management insists on using Scrum but that's just a workaround.

One thing to keep in mind is that the tasks need to be broken down to the size that is feasible to be delivered in 1 day.

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.