Incremental API Development

Joanna Koprovicz Agile Consultant

Joanna Koprowicz

How Agile Teams Can Deliver APIs* Iteratively in a Sprint, in Parallel with Development Work

Have you ever heard this one before?

“Our sprints used to be 2 weeks, but we couldn’t deliver, so we extended them to 3 weeks… and guess what? We still can’t deliver.”

This is a common frustration for Teams struggling to meet their Sprint Goals. The problem isn’t usually the length of the Sprint—it’s often how the Team works. No matter how long the Sprint, if the ways of working aren’t improved, Teams will continue to face the same challenges.
A similar issue often arises with API development. Many Teams develop APIs sprint(s) ahead of other work, making fully developed APIs part of the Definition of Ready (DoR). While this approach can work, it has some drawbacks. When requirements change, APIs often need adjustments, which can lead to Backend Developers having to redo work. 

Ideally, APIs should evolve alongside development, responding to ongoing feedback. So changes are guaranteed. 

While the traditional approach of developing APIs ahead of other work can be effective for some, it’s worth considering if there’s a better way. Can we, for instance, deliver APIs iteratively in sync with other development work within a Sprint? This could be a game-changer for many Teams.

Recently, I hosted a meetup organized by Agile-Lean Ireland, where Maciej Gowin, Head of Java Development at Ryanair Labs, shared his insights on iterative API delivery. As a lecturer and co-creator of the postgraduate program Programming in Java at Polish Universities, Maciej has a wealth of experience in integrating theory with real-world application.

He advocates for iteratively developing APIs within the Sprint, just like the rest of the product. This approach not only aligns API development with the overall product, but also opens up opportunities for continuous improvement and faster feedback loops.

Can APIs Be Delivered Iteratively in a Sprint while Balancing Needs of Both Business and Technical Teams?

Yes! Maciej highlighted that APIs don’t need to be developed ahead of other work. 

Although some Teams may be sceptical, this method has been proven to work efficiently in Agile environments. So, how can Teams make this happen?

Key Steps to Delivering APIs within a Sprint

The key to successfully delivering APIs within a Sprint is breaking them down into smaller, manageable components that evolve alongside the rest of the product. 

By prioritising the most critical parts of the API that directly support the features being developed in parallel, Teams can ensure that their API evolves in sync with the overall product. Maciej emphasized the importance of implementing minimum viable APIs that support the immediate needs of the Frontend while leaving room for additional features in subsequent Sprints.

This approach allows developers to receive early feedback and ensures faster integration and testing of APIs throughout the Sprint, keeping the Team engaged and proactive in the development process.

So how Can It Be Done?

1. API Stubbing and Mocking

Many Teams are now adopting this approach, using techniques such as API stubbing or mock services early in the sprint. 

These techniques simulate the behaviour of an API, allowing other components to be developed and tested without waiting for the API to be fully functional.

  • Stubbing provides predefined responses for early integration and testing. It’s beneficial when the API is still under development, but the frontend needs to move forward.
  • Mocking goes a step further, simulating both behaviour and logic. A mock can be programmed to behave dynamically based on inputs, making it ideal for more complex testing scenarios.

By incorporating stubbing and mocking, Teams can avoid bottlenecks and keep both backend and frontend work moving in parallel.

Key benefits of those techniques include:

Decoupling: Frontend or other services can proceed without waiting for the API to be fully developed.

Faster Testing: Developers can test functionality earlier with predictable responses. Mocks are useful in unit tests when you want to simulate specific behaviours or outputs, especially when the API’s actual functionality needs to be verified. They are also helpful for testing how your code handles different API scenarios. 

For example, a mock service might return different user lists based on parameters like user role or ID, mimicking the more complex logic of a real API.

Quick API mocks—a fake service representing the agreed model can be delivered by tools such as Mockoon or JSON Server. 

2. Versioning and Backward Compatibility

“So how do we manage the constant need for changes? What happens if, for example, we need to add a new field, like Date of Birth, to the API?”

API development rarely stays static. As requirements evolve, APIs often need to be updated. This is where versioning and backward compatibility come into play.

Maciej also recommended using tools that can trace which API versions are being used and deprecating unused versions or those with low traffic to avoid maintaining multiple versions unnecessarily.

If a new version of API is released, backward compatibility is essential. It ensures that applications or services using an old version of the API can continue to function without needing modifications. It prevents disruptions for users who have not updated to the latest version, maintaining stability and continuity.

For example, If you add a new field to the response (such as Date of Birth), the frontend developers shouldn’t experience a broken app if they are still expecting the older version of the API. The trick is to ensure that additive changes (like adding a field) are non-breaking, meaning older systems can still function without needing to update immediately.

On the other hand, breaking changes, such as renaming or removing fields, require more thought. This is where versioning comes into play—new versions of the API allow Developers to change the structure without impacting users who rely on older versions.

When versioning APIs, consider:

  • Clarity: Can users easily understand the versioning scheme?

  • Flexibility: Can the versioning system accommodate future changes?

  • Simplicity: Is the versioning method easy to implement and maintain?

  • Backward Compatibility: Does the versioning support older versions of the API?

3. Collaboration Between Backend and Frontend Developers 

Image of a Team Collaborating

Effective collaboration and clear communication between Team Members of a cross-functional Scrum Team are essential for ensuring that API development and frontend features align with Sprint Goals.  

When working on APIs, there’s often a disconnect between Backend Developers, who create the data, and Frontend Developers, who consume and display that data. This gap must be bridged to deliver fully functional software incrementally in each Sprint.

Maciej highlighted the importance of backlog refinement sessions, where both Backend and Frontend Developers meet to define API contracts, endpoints, and data models. These sessions ensure that both sides have a shared understanding of the API structure and can work in parallel without unnecessary delays.

Steps in collaborative API development:

  1. Define URLs and methods the frontend will call.

  2. Define the JSON model for data exchange.

  3. Keep communication open throughout the sprint, as APIs often evolve based on feedback and changing requirements.

The key to success is frequent communication and refining requirements early in the Sprint to prevent bottlenecks later.

 Backlog refinement session

As a part of the backlog refinement, Frontend and Backend Team Members should meet for 15-20mins to define API contracts, endpoints, and data models. Backend Developers need to understand how the API will be used, while Frontend Developers need to specify what they need. 

The Team needs to discuss and agree on the API model and ensure both Backend and Frontend Developers code against the model that was agreed together. The model can be defined using tools such as Swagger. 

This shared understanding helps all Team Members to work in parallel without unnecessary delays or misunderstandings.

However, the API usually evolves, and it also evolves during the Sprint. Developers need to update the models using tools that allow them to be shared across the Team.

Talking with Team Members of different specialities is always challenging, but the diversity of opinion brings the best solutions, so this is an absolute must. Working together as a Team should be a standard. 

Backend Developers should never look at the screens and UIs in isolation, trying to define the models. They get valuable input from the Frontend Developers, who know all the transitions and how they will go through the screen. Together, it’s easier to understand the flow, defined resources, URLs, and potential issues. 

If Frontend Guys define API, which is needed, they might need help understanding the complexity of the backend. Sometimes, under the hood, Backend Developers might have to call 20 systems to collect data to expose simple data like first and last name. In the beginning, you might think you will need 1 API to call to populate the data for one screen, but when you go through the refinement, you can discover that you need to call 3 endpoints.

Recommended practices:

Maciej recommended some good practices for API refinement. 

  1. Ask everyone to switch on the cameras. 
  2. Meeting: Min. 2 Backend + 2 Frontend Developers heavily involved in the process and knowing business requirements 
  3. Everyone to prepare the idea of the API before the meeting
  4. All to present how they see it
  5. Discussion to find a common way. 

Warning: A frequent problem encountered during the refinement sessions is when proposed model agreements are discussed. Typically, it’s a Lead Developer or Technical Lead speaking or only Backend Developers speaking. But if Frontend does not actively participate then Backend is not done in a way Frontend Developers expect it resulting in Frontend doing hacking, which is a bad practice. 

The data should be easily parsed and exposed on the frontend, while all the processes should happen on the backend. 

4. Incremental API Delivery

Delivering usable APIs in a small, incremental way each Sprint can be challenging, especially when endpoints are interdependent. Business views work from the UI perspective; they look at the screen and see 2 fields, not realizing that under the hood, Backend might have to call many APIs to for example authenticate the user and load the user’s data. So, we need to think wisely about which APIs need to be delivered first and how we will progress with the work so that we do not stop the Frontend from delivering business value. 

6. Managing Dependencies and Non-Functional Requirements (NFRs)

Coordinating between Teams and addressing non-functional requirements (NFRs)—such as performance, security, and scalability—is crucial to ensuring successful API delivery. As the API evolves, it might attract more traffic, requiring scalability. Regular performance testing and incorporating NFRs into Sprint planning help mitigate these risks and ensure that the API can scale as needed without compromising on quality.

7. Automating Testing and Documentation

 Automation is key to maintaining API quality. Automated tests—such as unit, integration, and performance tests—should be integrated into the CI/CD pipeline for immediate feedback and consistent quality and done within the sprints. The Automation Engineer would work against the model proposed at the beginning of the Sprint, and it all should work together at the end of the Sprint. 

It’s also essential to keep API documentation up to date, especially in fast-paced development cycles. Tools like Swagger can help generate automatic documentation based on the API model, which makes tracking changes easier and more efficient.

8. Handling Technical Debt

Iterative development can lead to technical debt, especially as multiple API versions accumulate.  Allocating time in Sprints for refactoring and technical improvements is a must-have.  This ensures the API remains maintainable and scalable over time.

Common Challenges in API Development

  1. Resistance: Developers sometimes are hard to talk to and are stubborn. But if you ask, ‘Have you ever tried that? They say no!’ 

The API is defined, but it is not working as it should. Even though the API was done in the previous Sprint, the approach needs to be refined in the next Sprint, so I recommend that you all sit down together as a team and try to rethink how you work.

  1. Translating Business Requirements: APIs often don’t interface directly with users, making translating business requirements into API user stories tricky. How clear are the requirements? Collaborate with the Product Owner to create technical stories and clarify business value. The user story will affect how we plan our APIs.

  2. Incremental Delivery: APIs are interdependent, and delivering usable increments in each sprint is tough. Plan API delivery around UI needs, ensuring the most critical pieces are developed first.

  3. Versioning and Backward Compatibility: Maintaining multiple API versions can lead to complexity. Gradually deprecate old versions and use tracing tools to monitor usage and manage versions efficiently.

  4. Managing Dependencies: Coordinating between Frontend and Backend  Developers can delay the progress. Use API contracts mock services to unblock Scrum Team Members to deliver value which can be presented to the business at the end of each sprint.  
  1. Collaboration: To avoid delays, foster strong communication between the Backend and Frontend teams. Agree on API models early in the sprint and prepare for API evolution as the sprint progresses.

  2. Non-Functional Requirements: Addressing performance, security, and scalability in short Sprints can be tough. As the API evolves, it might get more traffic, so we might have to prepare to scale the APIs and properly test them. Plan NFRs into Sprint work and conduct performance and security tests regularly. This will ensure that your API is robust and ready for growth.

  3. Testing: APIs are tested during UI testing, but it’s also recommended to use automation to test the API itself. Unit, integration, and performance tests should be part of the CI/CD pipeline for consistent feedback.

  4. Documentation: It is difficult to keep API documentation up to date in fast-paced sprints. Use automated tools like Swagger to generate documentation alongside development. Swagger helps describe the models by documenting the APIs and data exchange.

  5. Handling Technical Debt: Set aside time for refactoring to avoid piling up technical debt. Addressing debt early ensures long-term maintainability.

  6. Coordinating Release Cycles: Synchronize API releases with consumers (frontend and mobile teams). Tools like feature flags help manage rollouts without disruption.

  7. Accommodating Changing Requirements: Changes happen—be flexible and keep communication open to accommodate them.

By tackling these challenges head-on, teams can significantly improve their API delivery processes and embrace iterative, agile development.

The Verdict: Is Iterative API Development in a Sprint Possible?

Absolutely! With the proper planning, tools, close collaboration, and automation, delivering APIs in parallel with other Sprint activities can become your reality.

So, instead of asking, “Can we deliver an API iteratively within a Sprint?” Teams should start asking, “How can we make it work?”

Teams can unlock faster feedback loops and more efficient deliveries by breaking down APIs into manageable pieces, aligning backend and frontend efforts, and embracing stubbing, mocking, and automated testing.

So, the next time someone asks, “Can we deliver an API iteratively within a sprint?”—the answer should be, “Yes, and here’s how we can do it.”

*Application Programming Interfaces – essentially a bridge that allows different systems or services to interact with each other.