Ask HN: My company is forcing 1 week sprints. What should I do?

[mcsolid]

The leadership of the company I’m at is forcing all teams to do 1 week sprints instead of 2 because they believe that they can get more out of the teams and get better visibility into progress. We’ve debated for months that teams aren’t getting enough upfront time to plan while still taking on the same meeting load as 2 week sprints basically every week. All the engineers, leads and product leads want to as well. I don’t know what to do anymore. All the teams are getting burned out from meeting overload and not enough prep time. Any advice?

[datadrivenangel]

Is the team/company's engineering culture decent otherwise?

Ultimately, someone at the company wants to have software that makes them more money or keeps them from worrying about losing money or going to jail (compliance.

Someone at the company thinks they can improve the state of software maintenance/delivery by changing the process. Maybe this is a VP accommodating a micromanaging CEO and doing something so that they can be seen doing something, but it could also be a well-intentioned change, in which case they want either more productivity -- with the theory that more software sooner results in more value -- or more predictability, with the theory that managing teams more closely results in less surprises and delays.

Identifying the root motivation may help propose alternatives, so it may be worth talking 1-1 with someone in leadership to try to understand the motivation. "On team X we're going to move to 1 week sprints. For my contextual awareness to better help implement this change, are we primarily hoping to increase predictability, even if velocity ends up decreasing, or should we focus more on increasing velocity even if work ends up carrying over?"

[mcsolid]

I like focusing on the root motivation. I haven't been able to get to it based on previous conversations. It seems to be perceived velocity because of the increased visibility from what I've gathered but the fact that we don't even have the option to experiment leads to a bigger issue IMO. The teams just aren't empowered to adjust course.

[datadrivenangel]

See if your manager knows what's going on. They may be just as oppressed as you feel!

And they may be willing to go along with smaller secret team-level experiments. Maybe Kanban will result in even better visibility and performance! (And satisfaction)

[mcsolid]

Yeah, unfortunately I did and have been declined several times to experiment. I've also suggested Kanban too since it feels more in line with the pace and the lacking requirements and also shut down several times.

[datadrivenangel]

Do the experiment at the smallest level possible. And if not, it's time to suck it up or find a new job.

[joezydeco]

Break every story into an obscenely large number of subtasks or tickets and bury the backlog. Make it so large that the amount of time sorting and planning will take most of the week. Stick to the work in each ticket and don't work on the next ones until the sprint is closed.

[JojoFatsani]

Agile is extremely gamable.

That said.. just break the tasks down to as small and granular as possible and take on fewer.

[kasey_junk]

Start tracking meetings as points. Make sure to count the prep and unload time from the meetings. Add research, design and planning tasks pointed as well.

You’ve got leadership that doesn’t understand how to deliver software, but you also almost certainly have a transparency problem. You probably can’t do much about the former but you can the latter.

[giantg2]

I would look to leave. If they're that stupid to think a shorter sprint time will increase velocity, then they are likely making other stupid decisions. It also doesn't look good financially if they're grasping at straws to increase velocity like that.

[mcsolid]

That’s what I was inferring as well. What does it say about underlying business that isn’t getting communicated.

[TheMongoose]

Realize that when a company is doing Agile at you that everything is made up and the points don't matter. Make your t-shirts smaller and do whatever you were going to do anyway.

[mcsolid]

They are also forcing time based pointing onto the teams too. 1 point per engineer day. There are other issues with the leadership expecting each engineer to be able to support 5-6 “points” a week but that’s another story.

[TheMongoose]

Still doesn't matter. Make Jira say whatever they want. Or you could enjoy applying endlessly in the currently completely hosed job market.

[jf22]

Yeah all this stuff is meaningless. The work is still the same. All that changes is the bullshit you type into JIRA boxes.

[ManlyBread]

The worst thing you can do is to try and make it work. Do everything in your power to make that idea fail, since that is the only way your management will change their minds.

[scarface_74]

Yes they may change their minds about keeping him employed

[mcsolid]

Yeah it’s already failing which is why I’ve been trying to change the thinking.

[ManlyBread]

Good luck trying to convince potential new employees to come and work in 1 week sprints

[scarface_74]

You haven’t looked for a job lately have you? I was looking for bog standard enterprise dev jobs as a “Plan B” last year and the year before last.

Every single opening had literally hundreds of applicants in the first week - LinkedIn Quick Apply - shows you.

Hiring managers say the same thing.

[solardev]

Start looking for a new job... once a company starts going down that path, they're bleeding to death and trying to band-aid it. It won't work. It's a sign of desperation and poor management that usually won't be reversible.

[markus_zhang]

This is the right answer.

[scarface_74]

Do your job for 8 hours a day, close your computer and wait for money to appear in your account every pay period.

“Once the avalanche has started, the pebbles no longer have a vote”

[muzani]

I find 1 week ideal without the overhead.

Remove unnecessary demos or retros. You need the feedback cycle but often 1-3 months is fine, and 2 weeks is only useful for a beginner team.

You do need planning, context, and meetings to discuss the context. We moved these to two days a week where anyone is free to interrupt anyone else and call for a call right now. Nobody expects to be in flow on these days. But as we got better at teamwork, we only needed 0 or 1 days.

We do have 1 week sprints but it's about 90 minutes of sprint related meetings/week on average and that includes stand ups, retros and demos.

Work estimation into the schedule. They're called spikes. Time box them. No commitment is made without the confidence of the spikes. If you don't have confidence by the end of the spike, then something is wrong - the requirements is unclear, code is too opaque, you don't have the data, someone isn't cooperating, etc. These are all very valid outcomes of a spike. Maybe you need to call someone. Maybe you need to refactor.

[mcsolid]

Saying this probably indicates more problems but they also insist on demos each week and demos/retros every 2 weeks. Also they want metrics/retros to track team velocity.

How much time per week do you have dedicated to sprint meetings? Another issue we have is requirements are always lacking because it’s always fires (and everything is P1).

[muzani]

The most efficient form I've seen is one 30 min meeting to discuss what we plan to do and what went wrong/well with previous plans. And a second 60 min meeting at the end of the week to show what we've done, the impact, and the GTM plan.

But if you have frequent P1 fires, then you definitely need the retros quite often. In our case, we always do post mortems for a P1. We dig deep into root causes and this alone is a significant meeting. If it's P1, then, well, it should take everyone's attention. If it's not that major, then it should be some other level. But they shouldn't be happening more than one a quarter or something. It's okay to not be adding features – sometimes reducing fires is significant progress, lol.

Sprint planning meetings for us is just 30 min. We update a doc, it doubles as the retro. Most of the tickets and stuff is already managed by Jira; PM just ticks what we plan to do that sprint. Requirements have already been reviewed before the meeting starts, the meeting is where we work out a plan for it.

[jf22]

Useless metrics, lacking requirements, tons of P1s and emergencies...

Sounds like normal career in development to me.

[thiht]

> Remove unnecessary demos or retros

Remove the 2 most important meetings in a functioning team?

[muzani]

If it's important to you, then keep it, of course. Every team is different just like all code is different.

The symptoms of too many meetings is people don't attend them, work during them, complain about not getting things done, etc. If the retros are working, you shouldn't need many of them. If they're not (which sounds like OP's case), then they should be less frequent.

Demos tend to be redundant. Most of the teams I worked with know exactly what the team just built; sometimes the CEO is QA. In the bigger teams, the stakeholders might be juggling too many things to attend anyway.

[owebmaster]

I think you can 10x this. Propose 1-day sprints. Make them understand that shorter sprints don't make development faster.

[akerl_]

Delete every meeting that isn’t directly related to either tracking the sprint, working on items on the sprint, or personnel management/growth, and then spent your time doing the work.

Or quit, I guess, if the difference between 1 and 2 week sprints is a deal breaker for you.

[quintes]

They just want faster delivery? Or more meaningful progress tracking?

Usually I find I want improved traceability of the work, and so that means clearly calling out:

planning, defining, scoping and building.

If those on the left are poorly completed that in the right will suffer.

[mcsolid]

Yeah this is exactly what we’re seeing too.

[quintes]

Perhaps then a gentle conversation about the entire pipeline that feeds the SDLC is necessary.

Are there agreed plans or do they change? Are they feasible.

Are sprints hap hazard with story changes, poor quality (and measured against what criteria) or team changes? Are resources sufficient and skilled?

There are many more questions but hopefully you get the idea

[toomuchtodo]

Start looking for your next job. When you land somewhere, bring with anyone worth bringing with. This assumes you have no leverage to prevent them from squeezing you and the team(s) harder.

[dakiol]

Why are you worried? It's not that you are goning to do the work of 2 weeks in 1. Just work as before; some things will work out and others won't.

[codingdave]

Honestly, quit.

Anyone still sticking to Scrum is already behind the times on creating an enjoyable work environment. If they are pushing for shorter sprints, they are doubling down on what makes it bad, not what makes it good.

I'm all for trying to make a place better before giving up, but this is one of the few leadership decisions that are an exception to my ideals. I would just walk out the door, no hesitation.

[mcsolid]

What are the alternatives? I would love to hear what works well so I know what to look for.

[markus_zhang]

Definitely don't walk out in this job market, but I agree with the gist. OP should find a new job and figure out a way to let the company layoff OP.

[nivertech]

Ask to move to 0 week sprints - aka KANBAN - no planning ;)

Ideally KANBAN should be used only for reactive work (bug fixing, ops, support, etc.), but I guess with incompetent management every work is reactive work :(

[jf22]

I've seen 1-4 week sprints work just fine.

Give it a try and if it fails, it not on you.

If you're burnt out from meetings and leaving is worth it then leave.

[jbellis]

for me the problem here is an org that debates sprint length for months

[mcsolid]

Exactly that being a problem within itself. It feels so counter to the philosophy of Agile being “people over process”. If the people are saying they need more prep time why aren’t they listening?

[cosmicgadget]

Adjust estimates accordingly?

[ff4]

I’ve got a system that I think could smooth things out for your team, especially since developers and management/biz people seem to be working on totally different wavelengths. Let me break it down for you in a chill way and explain why it could work.

developers and biz folks are basically living in two different time zones, work-wise. Developers need big blocks of uninterrupted time to think hard and get stuff done efficiently. When they’re yanked into meetings or forced to hop between tasks all the time, it kills their groove, and honestly, they end up getting less done. Meanwhile, the biz people—like your management or OWSP types who love to chat—want to see progress in the ticket system. And I get it—developer time ain’t cheap, so they’re stressing about whether the money’s being well spent or if people are just slacking off. But here’s the kicker: sprints themselves aren’t the bad guy. It’s really about the feedback loop—or lack of it—and how it makes everyone feel like they’re not on the same page.

End-of-Day Sync System Instead of those morning standups that mess with developers’ focus right when they’re getting started, we flip it and do a quick check-in at the end of the day. Developers get to work all day without interruptions, and biz folks still get their updates to keep the ticket system humming. Win-win, right? Here’s how it shakes out:

How It Works

Quick End-of-Day Huddle (15-20 mins, max): Everyone jumps in at the end of the workday. Developers say what they got done—did they finish their task, are they still grinding on it, or did they hit a wall? Then they grab a small task for the next day off the Kanban board—something they can knock out in 2-4 hours. Keeps it doable, no stress.

Biz Folks Do Their Thing All Day: While developers are heads-down coding, the management crew has the whole day to mess with the ticket system, shuffle priorities, and prep for the huddle. No more last-minute panic in the morning—they’ve got time to think it over and bring solid updates.

Tasks That Fit the Day: Developers pick their next task at the end of the day, so they can sleep on it and hit the ground running tomorrow. Since the tasks are small, there’s no pressure to pull all-nighters or play hero. Everyone clocks out on time—no burnout, no unpaid OT.

Keeping Biz in the Loop: This setup gives biz people daily visibility— they see what’s done, what’s next, and if anything’s stuck. It’s not about hovering over developers’ shoulders; it’s just enough to keep them in the know without breaking anyone’s focus. Plus, they can tweak priorities for the next day if stuff shifts.

Why It Beats the Sprint Chaos

Look, sprints aren’t evil—they’re just a way to chunk up work. But when you squash all the planning, reviews, and standups into a tight one-week sprint, it’s like you’re spending half your time talking instead of doing. This system keeps the structure but cuts the fat. That end-of-day sync replaces a bunch of those meetings, so developers can actually breathe and work, while biz folks still get their progress fix.

And let’s talk about that “slacking” vibe for a sec. When there’s no clear daily update, it’s easy for management to wonder what’s going on—especially since developer time is so pricey. But with this, everyone sees small wins every day. If someone’s not pulling their weight, it shows up fast—no blame game, just facts. Plus, developers get better at guessing how long stuff takes, since they’re sizing tasks daily and getting instant feedback. Oh, and the biz people? They love to talk—OWSP types especially, right? This gives them their stage at the end of the day without dragging developers into endless chats during prime coding hours. They get their ticket system updates, they feel in control, and developers don’t have to fake-smile through it all morning.

The Bottom Line Developers get their space to think and work efficiently, biz folks get their daily dose of progress without freaking out about costs, and nobody’s burning out. It’s all about respecting those two timelines—letting developers dig in deep and keeping management happy with a steady flow of info.