Since you mentioned you're a smaller startup the advice below is tailored to that. Many people who work in larger companies will likely be upset at some of this

Since you mentioned you're a smaller startup the advice below is tailored to that. Many people who work in larger companies will likely be upset at some of this advice as it doesn't reflect how this sort of change might apply to a larger company/team. Things that have worked at other startups in the past: 1. Explain to management/lead/whoever is above you that things aren't going well and you're going to change stuff up for ~1 to ~2 months and productivity may not be massively improved for ~3 to ~4 months out. They have to understand things might get worse before they get better. 2. Drop the notion of a "sprint" and switch to a kanban like workflow for a little while. Work with management to find the highest priority issues and use the priority field in your ticket system to track what will have the highest impact. You should meet with your boss 1/week to update these priority so they stay current. The goal here is to stop commiting to any work because that's a skill that hasn't been developed in your team yet. If you are commiting to things and 100% of the time you fail to meet your commitments you're essentially alrady doing kanban with waaay more artificial stress. 3. Do a (~weekly) call with engineers and estimate the effort/difficulty behind each of the next N tickets in your backlog. N should be ~5*$num_engineers - 5x is used because it's small enough so people aren't overwhelmed by the work but they still know what's coming down the pipe. You should not impose anything in this discussion, just be quiet and let the engineers talk until they all agree. There's going to be a lot of bike shedding and as management your main goal is to keep everyone laser focused on what the effort things are and what the blockers are. You should also ask the engineers how to break up bigger issues into smaller work items if they are lower priority. Focus on lower priority items for this type of breakup because this is a hard to learn skill and if you need to deliver meaningful features WHILE doing this team change up you'll be having a hard time shaking up the process for critical work. This meeting is essentially going to demolish an entire work day and everyone will hate it. 4. During each of these meetings you will secretly keep notes on what you hear being brought up. I'm assuming you're not technical and if that's the case look for "we can't do that because $x isn't really able to be used like that" or "we hit another limit in $y and using it is a pain in the ass" or "after we deployed $z we found that it wasn't at all the same as our dev environment". You will then schedule a weekly catch up with every engineer (most junior -> most senior) and ask them how work has been going and bring up some of the things you've heard about. When talking to the most senior engineers ask them if they have ideas for how to fix these issues. If they do ask them to make some tickets in the backlog, if they don't add a investigation ticket into the backlog. 5. During your next meeting with the people who set priorities choose some amount of tickets (~20%) to include into the top of the backlog. 6. Have a 1/quarter meeting with all engineers and discuss what the goals are for the next quarter. Ask each engineer to take 1 thing to accomplish by the end of the next quarter that will deliver measurable business value. These goals should have accompanying tickets in the backlog. This is to help reduce bystander effects and to make it clear that "my job is to ship X by Y". 1 quarter is a long enough time that most people thing "pfft that's so far away it's not really a deadline" but short enough that you aren't going to sink or swim over that timeline (hopefully your runway is longer than 4 months). 7. Track the amount of output of the team. If you are using points to estimate how hard things are then use that as a (shitty) proxy for measurement. You want to see #-tickets/week and #-points/week rise. Once they've risen to a high enough level talk to engineers about work/life balance. If everyone is super happy then don't fix what ain't broken. If everyone is super unhappy talk about going back to a sprint-based workflow with the team and help them choose a number of tickets that makes them feel less overwhelmed. 7. If you're still not hitting quarterly business goals that you and management are setting after ~6 months and the engineers are unhappy ask them to help you invest in educating them. Interview some consulting companies as a team, look for good talks, etc. Outside eyes may be able to help spot what's going wrong. I'd love to hear from others about how this process could be improved because I've only ever implement these processes internally at a company and no one ever gets to see/grade that work.