When planning in Scrum, the first thing to realize is that you should not try to plan the work to keep everybody busy, but rather you should try to plan a certain amount of functionality that your team will try to deliver at the end of the sprint.
In Scrum, the input to the planning is the product backlog, which should contain the desired features in the order that they provide the most value to the business. During the planning, you take items from the top of the product backlog until you have enough work to fill a sprint.
If the top of the product backlog happens to contain a lot a features that involve mostly front-end work, then it can happen that the sprint is "full" before you reach the 200 story-point mark. Full here means that the front-end developers are fully loaded.
Within the Scrum framework, there are a few possibilities to deal with this situation:
- If you foresee a lot of back-end work coming up in the backlog, which would result in the same situation in the next sprint, you can negotiate with the Product Owner to exchange some front-end heavy stories for back-end heavy stories to create a more even workload over the team.
- If there is nothing suitable to exchange, or if the Product Owner doesn't agree with a swap, then it is good to realize that there are always tasks that can be picked up by any team member. If there are no back-end related tasks that the back-end developers can work on, they should try to assist the front-end developers to the best of their capabilities so that the team can finish the work the planned.
Examples of work that the back-end developers could pick up are:
- Write test specifications
- Execute manual tests
- Write unit tests
- If they have some familiarity with the front-end technology, perform reviews
In Scrum, the goal should not be that you as individual work at maximum capacity/productivity, but that the team produces that what benefits the business the most.