Coder Legion - Recent posts tagged scrum

How Sprint Planning Actually Works

Tue, 02 Jun 2026 20:19:31 +0000

The high-level view of software development looks pretty straightforward. A team gets requirements, starts designing, writes code, tests features, and finally delivers the product.

Simple… right?

But when you look deeper into how software development actually happens inside teams, the reality starts feeling very different.

What seems smooth from the outside rarely feels that smooth while building the product in real life.

Tasks change. Priorities shift. Bugs suddenly appear in between. New ideas get added while development is already going on. And before anyone even realizes it, the team is managing multiple things at the same time.

When work starts moving in too many directions together, things can get messy very quickly.

That is exactly where Sprint Planning comes into the picture.

Before teams start building anything, they need a moment to pause and get clear on the work ahead. Not in a heavy or overly formal way — but enough to make sure everyone is moving with the same understanding before the sprint begins.

Because when that clarity is missing, development may still start… but confusion usually starts with it too.

And that is what makes Sprint Planning such an important part of Agile teams.

In this article, we’ll understand how Sprint Planning actually works — in a much simpler and practical way, with relatable examples, without making it feel overly technical or textbook-like.

Why Modern Software Development Needs Better Planning

Have you ever wondered why teams struggle while building products even when everyone on the team is talented and knows what they’re doing?

At first, it feels surprising. Because when you look at it from outside, everything seems fine. Everyone is skilled, work is moving, code is being written, and development has already started.

So naturally, the question becomes — then where does the problem actually begin?

You might think maybe the team lacked coordination. Maybe communication broke somewhere in between. Or maybe there was confusion while people were working together. And yes, sometimes that can absolutely happen.

But many times, the real issue starts much earlier than that — even before development begins.

A lot of teams unknowingly begin with a very simple thought:
“Let’s just start building first. We’ll figure things out along the way.”

And honestly, this doesn’t feel wrong in the beginning. In fact, it feels faster.

Planning feels like extra work. Documentation feels time-consuming. Meetings feel unnecessary when everyone is already excited to start building something.

So the thinking becomes simple — why spend time planning now when we can use that time to code?

But this is usually where things slowly start becoming difficult later.

Because development may start fast, but keeping that momentum becomes difficult when the work keeps changing while the product is being built.

New requests come in. Priorities shift. Feedback keeps arriving. Small decisions made early start affecting things later. And gradually, work starts feeling heavier than it looked in the beginning.

That’s when teams realize building the product was never the difficult part. Managing the moving pieces around the product is where things become challenging.

That’s why modern software teams don’t see planning as “extra work” anymore.

They see it as something that creates enough clarity before development moves too far ahead.

But at the same time, planning everything months in advance doesn’t work either.

Because software keeps changing while it’s being built. User needs evolve. Product direction changes. And sometimes what looked important in the beginning doesn’t stay important later.

Which means teams needed a better way to plan work — without trying to predict everything too far ahead.

That shift changed how modern teams started building software.

And that is where smaller development cycles entered the picture.

How Smaller Development Cycles Changed Modern Teams

Earlier, many teams used to build large parts of a product over a long period before releasing anything to users. Sometimes it would take months before users could even see what was being built.

At first, this approach sounds practical. The thinking feels simple — finish everything properly first, and then release it once it’s fully ready.

But in real software development, things rarely stay the same for that long.

While the team is busy building, user expectations keep changing. Feedback keeps evolving, market needs shift, and sometimes even the product starts moving in a slightly different direction midway through development itself.

And by the time everything is finally ready, some parts may already feel outdated or need changes.

That’s where teams started facing a bigger problem.

They were spending a lot of time building, but learning very late whether they were actually building the right thing. And making changes late in development is never easy — it usually takes more time, more effort, and sometimes means reworking things that already felt completed.

That’s why modern teams slowly started moving away from one long development cycle.

Instead of building everything together at once, they started breaking work into smaller parts and delivering it step by step. This made it easier to release earlier, learn earlier, improve earlier, and keep moving with real feedback instead of relying only on early assumptions.

Think about an app like Rapido or Uber.

Imagine trying to launch it with everything built together at once — login, booking, payments, live tracking, notifications, offers, ratings, support, and every other feature in one go. It would take a huge amount of time before users could even start using it.

Instead, teams usually start with something smaller. They release the core experience first, let users start using it, and then keep improving the product gradually over time by adding more features in future updates.

This way, users start getting value much earlier, while the product keeps improving step by step instead of waiting until everything is fully completed.

Breaking work into smaller cycles helped teams adapt faster and learn earlier. But it also created a new challenge — making sure every new cycle begins with enough clarity before the actual work starts.

So What is Sprint Planning Actually?

Once teams started working in smaller development cycles, something else naturally became important.

Every cycle needed a proper beginning. Because teams can’t simply jump into work every few weeks and expect everything to automatically fall into place.

Before development starts, there usually needs to be a quick pause.

A moment where everyone comes together, looks at what’s ahead, talks things through, and makes sure the sprint begins with shared understanding instead of assumptions.

That is what Sprint Planning feels like in real teams.

It’s less about meetings for the sake of meetings, and more about giving the team a clear starting point before the actual work begins.

Because once development starts moving, things move fast.

People get busy in their own tasks. Different parts of the product start moving together. Conversations happen alongside coding. And there’s often very little time to stop and rethink once the sprint is already underway.

That’s why teams usually take this time beforehand.

Not to over-plan everything. Not to predict every situation in advance.

Just to align around the upcoming work, build a shared understanding, and begin with better clarity together.

And that small pause before the sprint begins often saves a lot more time later while building.

Where Does All The Work Come From?

While understanding Sprint Planning properly, one question naturally comes up first:

Where does all the work actually come from?

Because before a sprint begins, the team already has work in front of them. Features need to be built, bugs need fixing, improvements keep coming up, and new ideas keep getting added over time.

So naturally, all of that has to come from somewhere. And if you think about it closely, the answer is actually pretty simple — it starts with the users.

Because at the end of the day, every product is being built for someone to use. And once people start using it, their experience with the product starts shaping what happens next.

Think about apps like Swiggy or Zomato.

Suppose users start wanting the option to order from multiple restaurants in one single order. If enough people keep asking for something like that, the company starts paying attention. Because now it’s no longer just an idea — it becomes something users genuinely care about.

And this is how many product improvements usually begin.

Users may never directly sit with developers and explain what to build. But through reviews, feedback, complaints, feature requests, and even the way they use the product, they constantly shape how the product evolves over time.

Now obviously, thousands or millions of users can’t directly join the team’s discussions. So someone needs to represent that perspective inside the team. And in Agile teams, that role is usually handled by the Product Owner.

You can think of the Product Owner as someone who stays close to both sides — understanding what users are experiencing, while also staying connected with the product and the team building it.

Over time, all those needs, requests, improvements, fixes, and ideas start gathering in one place. And that running list is what teams call the Product Backlog.

It’s simply a place where upcoming work lives before the team begins working on it.

And that’s usually where the team looks before a new sprint begins.

How Teams Decide What Fits Into a Sprint

As soon as the team has the Product Backlog in front of them, one important question naturally comes up:

What can actually be taken into this sprint?

Because the backlog usually contains much more work than the team can finish in one cycle. There may be multiple features, fixes, improvements, and ideas waiting there together — but obviously everything cannot be picked at once.

So the team sits together and starts looking through the upcoming work. They discuss what feels important right now, what makes sense to take next, and what can stay for later.

But this is not just about picking work from a list.

The bigger conversation usually begins when the team starts understanding how much work something actually involves.

Because sometimes a task looks very small from the outside… until people start talking through what it really includes.

Take a login feature for example.

At first it sounds simple — just add login to the app.

But once the team starts discussing it properly, more things begin appearing around it. Authentication, validations, password reset, session handling, security checks, database connection, error states — and suddenly the same task feels much bigger than it looked in the beginning.

And this is exactly why teams discuss before deciding.

They try to understand the work from different angles before bringing it into the sprint. Sometimes it feels smaller than expected. Sometimes much bigger. And many times the real effort only becomes clearer after the conversation begins.

Teams also look at how much work feels manageable for the upcoming sprint based on the time and people available during that cycle.

And once that clarity starts forming, some work gets picked for the sprint, while the remaining work stays in the backlog until a later time.

And that’s completely normal.

Sprint Planning is rarely about fitting everything in.

It’s more about starting with a realistic amount of work that feels clear enough for the team to move forward together.

Why Sprint Planning Often Fails in Beginner Teams

Even after understanding how Sprint Planning works, many teams still struggle with it in real life.

And honestly, that's a challenge most teams face when they start applying it.

Almost every beginner team goes through this phase at some point. Not because they lack skill, and not because they’re doing something terribly wrong — but because planning feels much easier from the outside than it actually feels when the team sits together to do it.

One of the most common things that happens is teams take on more work than they realistically should.

At that moment, everything feels doable. A task sounds manageable, then another gets added, then one more joins because it feels important too. And slowly, without anyone noticing, the team commits to more than it can comfortably complete.

This usually doesn’t happen because the team is careless. In fact, it often happens for the opposite reason.

People feel motivated. Everyone wants progress. Everyone wants to move fast. And when useful work is sitting in front of you, saying “let’s take this too” feels much easier than pushing it to later.

Another place where teams struggle is during discussion itself.

Sometimes everyone walks out of Sprint Planning feeling aligned — but once work begins, people realize they were understanding the same task in slightly different ways. And that small difference becomes visible only after development starts.

Someone imagined a basic version of the feature. Someone else thought edge cases were included. Another person assumed part of the work was already covered somewhere else. And suddenly a task that looked clear in the meeting starts creating confusion during the sprint.

That’s why Sprint Planning usually works best when teams keep the conversation practical and honest.

Not rushed just to move faster. Not overloaded just to fit more work in. And not based on assumptions like “we’ll somehow manage later”.

The goal is simply to make sure everyone starts with enough clarity before the sprint begins. Because when that clarity is missing in the beginning, teams usually spend far more time fixing confusion later.

And that’s exactly where many beginner teams struggle without even realizing it.

Sprint Goals — The Part Most Teams Ignore

Once the team has decided what work will go into the sprint, it can feel like Sprint Planning is pretty much done. Tasks are selected, discussions are finished, and everyone feels ready to start building.

On the surface, everything looks sorted and clear. But even after all that, there’s still one small thing many teams forget to talk about before the sprint begins.

And surprisingly, that one small thing can completely change how the sprint feels later.

The question is simple:

What are we actually trying to achieve in this sprint?

Because a sprint usually isn’t just about picking tasks and completing them one by one.

If the sprint is only a list of unrelated work items, the team may stay busy the entire time — but the work can still feel disconnected while doing it.

This is exactly where Sprint Goals start becoming useful.

A Sprint Goal gives everyone one common direction behind the work already selected.

It brings all those individual tasks under one bigger purpose, so the sprint feels connected instead of scattered.

For example, imagine a sprint includes fixing login issues, improving password reset, and adding email verification.

These look like separate tasks when written individually. But when you step back and look at them together, they’re all improving one part of the product — the login experience for users.

And suddenly the sprint feels much more connected.

Different people may still be working on different pieces, but everyone is contributing toward the same outcome.

Now compare that with a sprint where one task is a small UI fix, another is a payment issue, another is dashboard cleanup, and something else is unrelated backend work.

All useful tasks. But together, they may feel like separate pieces moving without one clear direction.

That’s why Sprint Goals often help more than teams initially expect.

They create focus without making the process heavier. They help everyone stay aligned while working, and they make the sprint feel less like “just finishing tasks” and more like building toward something together.

It’s a small part of Sprint Planning. But many teams only realize how important it is once they start working without one.

Sprint Planning is Not About Predicting Everything Perfectly

After reading everything so far, it’s easy to get the impression that Sprint Planning is supposed to make the entire sprint go exactly according to plan.

The team discusses the work beforehand, agrees on what it plans to build, and starts the sprint with much more clarity than before.

And honestly, that sounds great.

But real software development has a habit of reminding us that reality often looks different from the original plan once the actual work begins.

Think about your own plans for a moment.

Have you ever planned your entire day perfectly in the morning, only for something unexpected to appear a few hours later?

Maybe a new task showed up. Maybe something took longer than expected. Maybe your priorities changed halfway through the day.

Software development is not very different.

Even when a sprint starts with a good plan, the team keeps learning while building. New information appears. Better ideas emerge. Sometimes the team discovers things they simply couldn't have known during Sprint Planning.

And that doesn't automatically mean something went wrong. It just means the work is now being seen more clearly than before.

This is exactly why Agile teams don't treat Sprint Planning like a prediction exercise.

The goal isn't to figure out every single thing that will happen over the next few weeks. The goal is simply to begin with enough clarity so the team can move forward together. And if something changes later, the team adapts and keeps moving.

Because Sprint Planning was never about creating a perfect future.

It was always about creating a better starting point.

Before understanding how Agile teams work, Sprint Planning can easily look like just another meeting on the calendar.

A meeting that happens before development starts. A meeting people attend because the process says they should.

But once you look at everything happening behind the scenes, it starts feeling very different.

A team isn't just writing code. People are discussing ideas, building features, fixing problems, making decisions, and working together on the same product at the same time.

And when all of that starts moving without enough clarity, even simple work can become harder than it needs to be.

That is why Sprint Planning exists.

Not because Agile requires another meeting. Not because teams enjoy spending time planning. But because spending a little time thinking together before building is often much easier than dealing with confusion later.

And maybe that's the biggest takeaway from Sprint Planning.

The goal was never the meeting itself. The goal was helping teams spend more time building and less time figuring things out along the way.

Because once the sprint actually begins, the conversations don't stop. The decisions don't stop. And the collaboration doesn't stop either.

In many ways, Sprint Planning is simply the point where the sprint starts — not where the work ends.

Why Your Story Points Feel Arbitrary (And How to Fix It)

Wed, 13 May 2026 15:55:00 +0000

This article was originally published on Medium.

I just feel it is "2", no, I think it is "3".

When I first came across story points, I always wondered how the "experienced" people on the team were calling out numbers so confidently. Now that I've become one of those "experienced" people — I realized I still didn't have a stronger framework for it. Like everyone else, I'd gone with gut feeling. Others would nod along, and sometimes we'd walk out with no real sense of why. All I knew was it should follow the Fibonacci series. Everyone had different intuitions, and the loudest voice — or the consensus — won.

So I tried to build a mental model for myself (not used by the team, yet), so I'd have something to point at when I picked a number. This is what I landed on after trying it on a couple of story-pointing sessions.

The four dimensions

Story points are supposed to capture how big the story would be, but the word "big" can pack in a lot of things, so I unpacked it into four things that I could actually measure:

Complexity — How hard is this to build? New tech, tricky logic, or big design decisions push this up.

Effort — How much work is there? A lot of small, easy changes across many files can still be Medium or High here, even if each change is trivial.

Uncertainty / Risk — How clear is the requirement? Open questions, unfamiliar parts of the system, or things that might surprise me mid-way add risk.

Dependencies — Does this depend on other teams or systems? This one is about waiting, not work. And waiting still inflates the point value. Every time the work unblocks, I have to re-page the state back into my head — and a story that crosses sprint boundaries carries its own cognitive overhead and spillover risk. Some people would argue dependencies shouldn't affect the size at all — they're not work, just calendar drag — but for me the cognitive overhead is real enough that they belong in the rubric.

For each, I rate Low, Medium, or High.

Rating guide

Dimension	Low	Medium	High
Complexity	Pattern we've done many times	Some design decisions needed	New tech, design-heavy, or novel problem
Effort	Single small change	Multiple changes, moderate scope	Many files / modules / large scope
Uncertainty / Risk	Requirement fully clear	Some open questions	Significant unknowns
Dependencies	None external	One known, manageable	Multiple, or blocked on another team

How I map ratings to points

Roughly, here's where I thought it made sense. Your numbers will probably differ once you've used this a few times — and they should.

Ratings	Points
All Low	1
One Medium, rest Low	2
Multiple Medium	3
One High	5
Multiple High	8
Mostly High	13

Do not be mechanical about this, it works now for me, can change in future.

Sanity check: if a story lands at 8 or 13, ask whether it should be split before you size it. Stories with several high-rated dimensions are usually epics in disguise.

How I actually use it

I rate each dimension in my head before I name a number. The dimensions are the work; the number is just the output.

The biggest thing I noticed isn't that I'm picking better numbers — it's that I can finally say why. Before, "5" was a feeling. Now I can trace it back: complexity High, dependencies Medium, the rest Low. Even if I don't share the breakdown out loud, having it in my head means I'm offering an estimate instead of a guess. And when I disagree with the room, I have something specific to point at — "I think it's a 5 because the unknowns here are bigger than they look" — instead of defending a number on instinct.

This is a starting point, not a strict formula. Override it when experience says otherwise. After a few sprints, look back at the stories that surprised you — were the surprises about complexity? Dependencies? Something else? Adjust the dimensions and the ratings to match what actually drives your estimation misses.

What this is not

This doesn't convert to hours, and it shouldn't be used to measure individual productivity.

The number isn't the point. The four-dimension conversation that produces it is.

Thank you for reading, suggestions are welcome.

Follow me on LinkedIn: Raj Kundalia

SprintPulse

Sun, 25 Jan 2026 06:02:08 +0000

What are retrospectives and why do they matter?

A retrospective is a structured team meeting - typically held at the end of a project, sprint, or work cycle - where everyone reflects on what went well, what could have gone better, and what to try differently next time. It sounds simple, but done consistently, retrospectives are the single most effective practice for building teams that continuously improve. They create space for honest feedback, surface problems before they become crises, and give every team member a voice in shaping how work gets done. Research consistently shows that teams who run regular retrospectives ship better products, have higher morale, and retain talent longer - because people want to work somewhere their input actually matters.

Why I built SprintPulse

Despite their proven value, most retrospectives fail to deliver. Feedback gets scribbled on sticky notes and forgotten. The same issues come up sprint after sprint with no resolution. Action items are assigned but never tracked. Enterprise tools promise solutions but cost a fortune and come bloated with features no small team needs. I built SprintPulse because I was tired of running retrospectives that felt productive in the moment but led nowhere. I wanted a tool that would capture honest feedback, surface real priorities, and - most importantly - ensure follow-through. Something designed for teams that actually ship, not committees that meet.

How SprintPulse makes retrospectives actually work

SprintPulse combines a clean, modern interface with genuinely useful AI features. Anonymous submissions create psychological safety so people say what they really think. Real-time collaboration means everyone participates simultaneously - no waiting turns, no lost momentum. Live voting surfaces the issues the team truly cares about, not just whoever speaks loudest. The AI is woven throughout the workflow: it suggests merging similar feedback so you are not discussing the same point three times, generates polished summaries the moment you finish, proposes concrete action items based on your actual discussion, and tracks recurring topics across retrospectives to spot patterns you would otherwise miss. Sentiment analysis shows how team morale trends over time, giving you early warning signs when something is off.

Give your team the retrospective experience they deserve

The difference between a useful retrospective and a forgettable one is follow-through. SprintPulse assigns action items to specific people with real deadlines, tracks them across sprints, and surfaces them at the start of each new session so nothing falls through the cracks. One-click exports send summaries straight to Slack or stakeholder inboxes without manual copy-pasting. All of this runs on EU-hosted infrastructure with GDPR compliance, at pricing designed for real teams - not enterprise budgets. If you have ever walked out of a retrospective knowing good ideas were shared but doubting anything would change, SprintPulse is built for you. Give your team a tool that turns reflection into results, and watch what happens when honest feedback actually leads somewhere.

Scrum Must Die ☠️

Tue, 19 Aug 2025 14:32:03 +0000

Scrum was born as the savior of development teams.
Now, in too many companies, it’s turned into a corporate religion with more sermons than miracles.
And like any bureaucratic religion... it either reforms, or it dies.

Scrum: from agile revolution to organizational theater

Years ago, when someone said "we're agile," people smiled.
Today, it means: "brace yourself for more meetings, more metrics, and more PowerPoints."

Once, companies hired Scrum Masters and Agile Coaches like rare Pokémon.
Now? They're laying them off, merging their roles, or keeping them as ceremony police.

The slow death of technical excellence ⚰️

Scrum doesn't ship technical practices out of the box.
Without a strong engineering commitment — tests, CI/CD, TDD, living architecture — the framework becomes a conveyor belt of broken features.

The result:

Code that ages worse than a banana forgotten in a drawer.
Deadlines that dictate more than quality.
Developers stuck in chronic burnout.

The mutant Scrum Master

In too many organizations, the Scrum Master is gone.
Instead, we have the Scrum-PM-Dev-Tester-CoffeeMaker: a hybrid creature that doesn't lead or serve, just survives.

A role meant to protect agility now spends the day filling spreadsheets and chasing tickets instead of empowering teams.

Management overload and the cost of ignorance

There's a growing management overload in many "agile" organizations: too many decision-makers with too little technical background.

This creates a dangerous loop:

Decisions are made without understanding the engineering impact.
Expensive mistakes are repeated in the name of "delivery".
Teams feel they're being managed, not led.

When non-technical managers dictate technical priorities, the result is often waste, rework, and long-term pain disguised as "progress".

The Agile Industrial Complex

Agility has been packaged into certifications, workshops, and consulting packages that promise transformation but deliver empty mechanics.

Scrum becomes a theater where everything is done "by the book" but without soul, values, or real continuous improvement.

Reform it or throw it overboard?

If you still want to rescue Scrum, here's the recipe:

How Scrum could improve:

Less ceremony, more value: if the daily stand-up lasts 20 minutes, something's broken.
Integrate technical practices: TDD, CI/CD, Pair Programming… without this, forget about quality.
Clear roles: a Scrum Master is not your Project Manager, boss, or on-call developer.
Real autonomy: the team decides, not the hierarchy.
Technical literacy in management: decision-makers must understand the cost and complexity of engineering work.

Alternatives that might shine brighter:

Kanban: flows like water, no forced iterations.
Extreme Programming (XP): hardcore engineering, quality above all.
Lean: less waste, more focus on what matters.
Mix & Match: take what works, drop what doesn't — like a good buffet.

Conclusion: Scrum isn't the enemy... but your implementation might be

Scrum doesn't have to die, but the zombie, bureaucratic, tech-agnostic Scrum we see in too many companies... that one should be buried.
Preferably with one last retrospective... and no sticky notes.

Understanding Tech Debt

Sun, 13 Jul 2025 07:21:40 +0000

Understanding Tech Debt

Understanding Tech Debt

What is Tech Debt in Software Development?

Think of technical debt (or tech debt) as taking a shortcut when writing code. You choose a quick and easy solution for now, knowing that you'll have to come back and fix it properly later. It's like borrowing money. You get something now, but you have to pay it back later, and often with "interest." This "interest" means that making changes to your software in the future will be slower and more difficult because of the shortcut you took.

What is Tech Debt in Agile and Scrum?

In agile development, where the goal is to release software in short cycles (sprints), teams can easily create tech debt. The pressure to finish work within a sprint might lead them to cut corners.

Here are some things to watch out for in agile:

Meeting Deadlines: Rushing to meet a sprint deadline can lead to messy code.
Changing Plans: When project needs change, the old code might not be a good fit anymore.
What "Done" Means: A good team agrees on what it means for work to be truly "done." This should include writing clean code.
Making it a Task: The best way to handle tech debt is to add it as a task in the project plan. This way, it doesn't get forgotten.

Common Examples of Tech Debt

Tech debt can show up in many ways. Here are a few common examples:

Code-Level Debt

No Instructions: Code without comments or documentation is hard for others (or your future self) to understand.
Not Enough Testing: Without good tests, fixing one thing can accidentally break something else.
Copy-Pasting Code: Writing the same code in multiple places instead of making one version that can be reused.
Mysterious Numbers: Using numbers in code without explaining what they are for.

Database Debt

Poor Normalization: Storing the same piece of information in multiple places. For example, having a customer's address stored with every order they make instead of in a separate customer table. This makes updates difficult and can lead to inconsistent data.
Inconsistent Naming: Using different names for the same kind of data in different tables (e.g., CustomerID in one table and Cust_ID in another). This makes writing queries confusing and error-prone.
Missing Indexes: A database index helps find data quickly. Without a proper index, the database has to search through every row to find what it's looking for, which can be very slow, especially with large amounts of data.
Ignoring Data Types: Storing data in a generic type (like a text field) when a more specific type (like a date or number) would be better. This can lead to bad data and makes it harder to work with.

Architecture and Infrastructure Debt

Tightly Coupled Components: Creating parts of the system that are so dependent on each other that changing one part requires changing many others.
Outdated Dependencies: Using old libraries or frameworks with known security holes or performance issues.
Lack of Automation: Manually deploying code or running tests when these processes could be automated. This is slower and increases the chance of human error.

Conclusion

Tech debt happens in almost every software project. Sometimes, taking shortcuts is necessary to get things done quickly. But it's important to keep track of these shortcuts and plan to fix them. If you don't, your software will become hard to work with over time. The best approach is to deal with tech debt regularly to keep your code clean and easy to maintain.