LinkedIn
Twitter
Overview
In order for any project based on Agile SCRUM principals to be effective all stakeholders need to be engaged, understand their roles and the different Sprint ceremonies need to be understood and well executed.
API development is well suited to this methodology with the ability to break development down into small manageable items and for a Test Driven Development (TDD) approach to be taken.
This article will focus on the typical Sprint ceremonies and how Apigee would recommend running an API development Sprint.
Schedule
The above schedule starts each Sprint on a Wednesday and runs for two weeks, finishing up on a Tuesday.
We find that avoiding starting and ending Sprints at the start or end of the week means you're avoiding common holiday times and also avoiding the most intense part of the Sprint i.e. closing out, coming at the end of the week when the team is likely to be most tired.
This schedule also means that any releases can be planned on Wednesday or Thursdays after the Sprints finish without having to wait until the next week (which probably would be the case if you finished the Sprint on a Friday).
Ceremonies
The majority of the ceremonies outlined above are the standard Agile best practice but there a couple of additional checkpoints above that we find useful and we also have a few pointers on getting the most out of the usual ceremonies.
I'm focusing on the Backlog Prioritisation and Grooming sessions before Sprint Planning as getting these elements right is key to the Sprint running smoothly.
Backlog Prioritisation
Although this is not usually a formal SCRUM ceremony many API programs find identifying a Product Owner who will proactively manage the backlog a challenge. Often we find it useful to have a Backlog Prioritisation session planned after the start of each Sprint for the Product Owner and the Scrum Master to sit down and review the plan for the next 2 - 3 Sprints so that priorities are clear and any dependencies can be identified and planned for e.g. the need for an API specification + test scripts to be created before development starts.
Without successful Backlog Prioritisation there's a danger that the delivery across multiple Sprints will not match the business expectation e.g. due to missed dependencies meaning that delivery of a given feature is delayed.
Backlog Grooming
This is an opportunity for the Product Owner to communicate to the team the new functionality that is being planned for the next few Sprints.
This provides the team with early visibility on what changes are planned and allows the team an opportunity to feed back to the Product Owner any issues they see that might need investigation before development starts (e.g. a SPIKE) or future changes that might need to be kept in mind / impact current development.
These sessions are not necessarily required every Sprint but are a key in order for the whole API Team to maintain a consistent view of what the platform is trying to achieve.
Backlog Grooming provides early visibility to the whole API Team of future features. This serves to de risk the future items on the backlog and prevent any surprises to the team either in terms of the features that are to be developed or the potential technical ramifications of changes.
Technical Grooming
This is not a formal SCRUM ceremony but once Backlog Grooming has been completed and in preparation for the next Sprint Planning session it's important that the Technical Lead and the Scrum Master add in any other tasks that are required to make the Sprint successful and that the Technical Lead ensures there is enough information to the How section of the tasks.
Without this activity there is a danger that the tasks for the next Sprint will not be 'Ready' and so estimation will not be possible or that additional technical tasks will be missed that will be required to complete the key features providing business value.
Sprint Planning
It goes without saying that the Sprint Planning sessions are key to a successful Sprint both in terms of making sure all items in the Sprint are 'Ready', that the team is committing to a realistic and achievable amount of work and that there is a clear definition of 'Done'.
The session is usually split into two
What and How
- What The Product Owner will confirms to the team the use case and business value that they are looking to achieve and makes sure the use cases are well understood
- How The Technical Lead confirms with the team the technical approach that is being proposed to achieve each item. The team works together to estimate each item (we would advocate the use of Story Points)
Any items deemed by the team as not being 'Ready' will be removed from Sprint scope and pushed into the next Sprint or the backlog.
From and API perspective a definition of 'Ready' might consist of
- Test cases defined e.g. Gherkin script
- Northbound API specification is defined i.e. what is to be returned to the API Consumer
- Mapping to and from Target payloads defined
- Non functional requirements defined e.g. Traffic Management, Caching, Analytics
- Definition of Done is clear
Not having a clear definition of 'Ready' often results in items getting blocked in the Sprint as not all required prerequisites have been delivered.
A key part of the definition of 'Ready' is that the definition of 'Done' is also clear.
From an API perspective a typical definition of 'Done' might consist of
- Unit and Integration Tests written and checked into SCM
- Code written and committed into SCM
- Pull / Merge request has been issued and approved
- Feature branch merged back into dev branch
- Unit and Integration Tests all pass in dev and test environments
- Any remaining technical raised as backlog items vs original scope
- API documentation updated with any changes agreed during development
Not having a clear definition of 'Done' typically causes items to be carried from one Sprint to the next or necessitates the need for additional technical or test debt items to be added into later Sprint to make up for deliverables that one of more stakeholders had assumed were going to be delivered.
Once both sessions have been completed the commitment for the Sprint will be confirmed based on the historical velocity.
It's also important at this point that the whole team has a clear idea of what the overall Sprint aim is and what is expected to be demoed at the end of the Sprint. This avoids disconnects between the business and delivery teams.
Sprint Planning Pain
Sprint Planning can sometimes become painful with the meeting running for hours and hours (ideally we'd recommend keeping the What and How sessions to 1.5 hours each) with lots of questions that can't be answered or extended discussions on what or how we're trying to deliver a given item.
This is usually down to a gap in one of the other Sprint ceremonies e.g.
- Missing dependencies
- Has the Backlog been correctly prioritised and groomed?
- Have the Scrum Master and Technical Lead added in the necessary additional tasks required to support the delivery of the key features (Technical Grooming)?
- Items not Ready i.e. What or How is not clear enough
- Has the item been through Backlog Grooming and Technical Grooming?
- Are priorities of items being switched around during the meeting?
- Has the backlog been effectively prioritised prior to Sprint Planning?
Demo
At the end of the Sprint the features developed should be demo'ed back to the Product Owner and other interested business sponsors in order to confirm the User Stories have been understood and that the expected business value is being delivered.
APIs can be seen as a very technical deliverable so it's important that the Demo shows the features delivered in a way that's easy for the audience to understand.
A technical audience may be happy seeing the APIs demonstrated using Postman or by running the associated test scripts e.g. a Gherkin file but for a less technical audience this might be less compelling.
Consider building a simple Web App that calls the API resources build and shows them in a real world context in order to help achieve stakeholder buy in.
This is also an opportunity for the business sponsors to make changes in terms of what they need vs what they have seen. This is not intended as an opportunity to completely change direction but to iterate on what they see.
Typically it helps to run the Demo in the morning of the last day of the Sprint to provide an opportunity for this feedback to be incorporated into Sprint Planning the next day.
Retrospective
As the team learns and develops, especially in the early Sprints, it's critical for the team to review what has been delivered and the approach being taken.
For API development there are many facets of the delivery from the development itself, testing, deployment, monitoring and source code management. Apigee provide guidance on all these aspects but it's important that whatever approach is taken is reviewed and improved upon each Sprint iteration.
Typically this meeting will happen after the Sprint Demo to incorporate all feedback and allow time for any suggested improvements to be incorporated into the next Sprint.
Summary
API development is well suited to the Agile SCRUM methodology but effective execution of the Sprints requires all stakeholders to understand and buy into the different roles, responsibilities and ceremonies.
Failings in one of the area of Sprint execution are often felt elsewhere in the process so if one part the Sprint does not feel like it's working its worth assessing if you're honouring the ceremonies in other areas.
I hope this article is helpful, all comments welcome.
