Scrum team with API + Client App
Hi All
just joined :-)
We have a real dilemma at the moment and we are having to break scrum rules. So need some input from experienced scrummers.
The product we are developing is really 2 in 1. We have an API and a browser app. The PO's don't consider the API, they only define the features. As a team we take the feature and split that into an API requirement and a FrontEnd requirement.
Our teams are NOT cross-functional. We have dedicated resources for DB / API / FE as we feel they are very specialised for our application needs.
So, in order to deliver the feature in one sprint, we would need to get all the required dev resources doing their work in time for that sprint. The problem is that we often end up with a feature that is FE heavy, but the APi needs are minimal. So if we stuck to the rules, the FE would be busy, but the API guys would be sitting around. The normal requirement would be that you create the FE and API as sub-tasks. However, this means that we cannot pull in other stories as they would never complete - the API sub would get done, but the FE sub would not.
So what we end up doing is that we split the feature into two stories - an API story and an FE story. Now we can pull in the right amount of tickets for each type of developer without the fear of not completing the whole story. What tends to happen is that the API guys prepare API tickets well ahead of the FE guys, who pick these up a sprint or two later.
This method works, but our PO's hate it as does not give them a single story encompassing the whole development stream, and we don't atually complete the feature in one sprint.
So, do we follow the purists and stick to the rules, or do we go with what works practically?
Z
Let's be clear about something from the outset. The problems the team is facing is a consequence of their not being cross functional. Team members are working in silos (DB/API/FE) and cannot "go to where the work is". As a result, each silo progresses at a different rate and their deliverables fail to synchronize at Sprint closure.
So, the right thing to do is to cross-train the team in order to remove these silos, and get them to work in a leaner and more efficient manner. However, you seem to have ruled this out as an option, which means that we must search for a reasonable alternative.
Now, you've made it clear that your current set-up is working in a practical sense. That's great, because it allows us to reduce the problem under immediate consideration to one of backlog management. That's where the pain is actually being felt...the PO's are finding API user stories on the Product Backlog which they do not value, and to which they quite reasonably object.
This means you need to get those API "stories" off the Product Backlog. Here are some options:
- treat API work as "Developer Stories" which the team manage themselves; they would plan them into Sprints themselves and reduce the available budget for User Stories accordingly.
- handle API development as development spikes with associated tasks.
Now let's consider a third option which addresses the silo issue:
- refactor the team so that the API development is handled by an separate API development team.
I'd suggest refactoring the team as a first move. You've said yourself that there are really two products in one, so it seems like a defensible direction in which to head. Product ownership for the API team would presumably be vested in the senior designers or architects. It would mean using component teams rather than feature teams, but in the absence of appropriate cross-functional team skills I suspect it might be the best option.
From the Product backlog prioritization point of view, I would assume that the FE features are prioritized at a much higher level then the API backlog. Usually product management would want new features delivered faster and would compromise on the API or integration resources in order to complete the FE features.
I am assuming that there is also a Middle ware layer in your FE/DB/API split ? The requirement usually is that the system behavior should be the same for FE and API requirement. If you deliver the FE and API in different releases than there is a one issue that I have seen come up. There might be some requirements that are implemented as FE layer validation. I you implement the API in a different sprint some of this validation can be missed and data quality issues might arise. From this point of view it is better to complete the API feature long with the FE layer and best way to solve this is to have a cross-functional team. Have you seen this in your case ?
The more complex scenario is that you have a core product and it has integration with some other third party system to provide some of its UI e.g BI reports. The API part of it can get complex if you dont get the buy in from the third party developers.
If you and your other team members having good grip in DB / API / FE then its will not so difficult. When you work on this keep communicate each other and discus what are you doing. A good team can make good result.