Manasseh Omachonu
Manasseh Omachonu is a Senior Software Engineer with over 8 years of experience building reliable, scalable, and high-performance cloud applications. He is passionate about developer productivity and clean architecture, and enjoys tackling complex distributed systems while keeping security and maintainability in mind.
Article by Gigson Expert
Software development can feel confusing for non-technical people. Even outside the workplace, developers often get questions like “So… what do you actually do?” or “Can you help fix my printer?” and similar questions. This shows that a lot of non-technical people have little idea of what developers actually do.
In the workplace, software development can also feel like a black box sometimes, especially for non-technical founders. You hire a team, define a vision, and after a series of sprints, they get some features released. What actually happens during a “sprint”? Why do features get released fast and then slow down other times?
What is a Sprint?
A sprint is a fixed time period, usually 1 to 2 weeks, where a team commits to delivering a set of predefined tasks. Sprints are designed to break large goals into manageable chunks, create predictable delivery cycles, and allow frequent feedback and adjustments.
During a sprint, teams meet daily to ensure alignment and commitment to the goal of the current sprint. Team members highlight what was done the day before, the plan for the day, and finally state any blockers that might prevent them from achieving their sprint goals. This keeps everyone aligned and increases the chances of delivering the sprint goals.
At the end of each sprint, the team demonstrates completed work and discusses what is working so far in the team and possible ways to improve the current process. Stakeholders can give feedback, and it's also a chance for founders to validate direction and catch misunderstandings early.
The Big Picture: It’s not Just “Writing Code.”
There's a common misconception that developers spend most of their time writing code. This is often not the case. In reality, what developers actually do at different phases of the sprint varies depending on the role/ project or company size and is part of a broader process that includes:
Understanding existing code or new requirements: When developers join a new project, it is important that they study the existing codebase to understand previous decisions and trace how the systems interact. For new requirements, they spend time analyzing and deciding how best to introduce the new feature without breaking the existing implementation.
Designing solutions: In the early phase of a new project or a major feature, developers spend days to weeks designing the solution. The design usually considers both functional and non-functional requirements and also ensures the design works well with the existing system.
Testing and debugging or refactoring technical debts: Solutions are often tested to ensure everything works as intended. Features or logic breaks most times and developers spend a significant amount of time figuring out (debugging) the problem before implementing a solution. Other times, the existing solutions do not work well or slow down the introduction of new features. Most times, this is likely because there were changes introduced that were not considered initially due to missing or unavailable information. In this case, developers need to possibly rewrite/ refractor the code to accommodate these new changes.
Meetings and discussions with teammates: Software development is a team sport, not a solo activity. Developers regularly meet with designers, project managers, and other developers to clarify requirements. According to a 2024 Stack Overflow survey, CTOs and engineering managers spend between 30% - 60% of the sprint in meetings and discussions.
Deploying and monitoring systems: Other parts of the sprint are spent deploying and monitoring systems in production. Developers also respond to production issues occasionally.
Why Sprints Might Not Go As Planned
From a founder’s perspective, a sprint can feel like a commitment. But from a developer’s perspective, a sprint is a best effort plan under uncertainty. Some sprints go so well that you might introduce more tasks from the backlog (a prioritized list of work the team plans to do), and other times it might not work as planned, and some tasks spill over to the next sprint. Here is why.
- Hidden complexity
A task might look simple on the surface, but hides complexity that might require database and backend changes, frontend updates, and integrations with other systems. Some of these issues are only discovered after starting the task.
- Unclear or evolving requirements
If requirements are not clear enough, developers make assumptions. These assumptions get corrected later based on new information. Even small changes in scope can have large ripple across the project.
- Quality Work Takes Time
It actually takes proper design to build great products. A good design takes time. It requires that you consider possible solutions and pick the one that best solves the problem while making accommodations for future changes. Rushing these phases can introduce technical debt and slower future development.
Impact of a “Simple” button change
At a glance, changing a button text from “Submit” to “Confirm” sounds like a minor UI update. But this is not just a simple text change, it is a change in the system’s behaviour. “Submit” usually implies sending data and finalizing immediately while “confirm” often implies review changes probably comparing with previous steps/revisions or an explicit user acknowledgement.
For this “simple” task, the developer might need to make the following frontend updates to support the new flow:
- Add a confirmation step (a modal or separate screen).
- Update validation logic probably stricter before confirmation.
- Change user messaging and error confirmation.
- Handle new states like “pending confirmation”.
To support this change the developer need to implement the following backend changes:
- Introduce a "confirmation state” (e.g. draft or confirmed).
- Implement logic to prevent immediate processing until confirmation is complete.
- Update business rules (e.g. only confirmed orders are processed).
- Handle retries or cancellation between steps.
To support the new logic, the database often needs updates that can involve schema migration and ensuring the existing data still works with new logic. A typical database update might include:
- Add new fields for status (draft or confirmed).
- Store timestamps for confirmation.
- Track who confirmed the change and when.
- Possibly support rollback or cancellation.
These changes may also require updates on the API for frontend and backend communication. New endpoints may be introduced, updates in the behaviour of existing endpoints, response format (e.g. include status). If the action triggers other systems, payments can only happen after confirmation, emails or notification changes. The developer might also need to add new test cases, ensure consistency across systems, handle partial states and implement solutions for various edge cases.
How Founders Can Help
Founders don't need to be technical to improve the team’s performance. The focus should be on
- Clear priorities because ambiguity kills productivity.
- Defined outcomes by also explaining “why you want this feature,” not just “what you want”.
- Avoid mid-sprint changes because changing direction mid-sprint reduces efficiency dramatically.
- Trust the process because sprint cycles are optimized for long term delivery, and short-term visibility can feel slow.
Conclusion
Sprints are simply a structured way to make software development more predictable and iterative. Asking questions like “What made this harder than expected?” leads to better conversations around the development process, and ultimately better products.
Developers don’t just write code; software engineering is about solving problems, managing complexity, and building systems that last. It is more accurate to say developers spend their time turning ideas into reliable working systems.
Frequently Asked Questions
Why can’t the estimation be precise?
Well, that’s why it's an estimate. There is likely some uncertainty.
Why isn’t coding happening all the time?
Thinking, designing, and reviewing are all essential to avoid costly mistakes.
Why does this small feature take a week?
Because “small” often hides complexity across multiple systems.
Can we just skip testing to go faster?
Yes, you can, but you might pay for it later with bugs and an unstable codebase.
Why didn’t this get done in the sprint?
Because the sprint also included work that wasn’t visible, problems that couldn’t be predicted, and interruptions that could be avoided.
