5

We are working to transition our development team to be more Agile. I have a question about story point estimation and their relationship to an individual's skill.

The scenario is that our team members do not have cross-functional skills. One might focus entirely on front-end, another only does back-end.

The problem we fail to plan accordingly to our team composition. We figure, if our average velocity is let's say 200 points per sprint, then that number should not be exceeded. However, tasks vary each sprint and sometimes there are too few back-end tasks or too few front-end tasks.

My question is - should we divide and plan back-end and front-end tasks separately, or is there a better way?

Improve this question
5
  • 1
    That's a tricky one. My understanding of Scrum is that it expects a team of generalists. Since that's not the case for you you're right in assuming you'll need to change things. I don't have any experience with this, but I would probably try to divide the planning into separate projects mapping to your team's skill silos (like you have already suggested).
    – MetaFight
    Jun 15, 2015 at 13:11
  • 1
    @MetaFight - Deciding to drop a major component of a methodology creates a slippery-slope of having to get rid of most of it or it just doesn't fit.
    – JeffO
    Jun 15, 2015 at 14:56
  • 2
    I wasn't saying it would be easy, or even a good idea. I was running under the assumption that training the team to be generalists wasn't an option. Maybe that was a bad assumption. You're right, though. A better path would be to invest in the team and train everyone to be generalists.
    – MetaFight
    Jun 15, 2015 at 14:59
  • 1
    How exactly do the tasks vary? If you're looking at a piece of functionality to be delivered (the user story), to be "done" is it really ONLY front end or back end work? Is there a tendency towards more back end than front, or vice versa?
    – Matthew Flynn
    Jun 15, 2015 at 16:09
  • 1
    @MetaFight - I think your first comment should be an answer.
    – JeffO
    Jun 16, 2015 at 8:07

4 Answers 4

Reset to default
3

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
    • etc.

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.

Improve this answer
1
  • Totes agree. People are so concerned about fitting workers in boxes, front end/backend/dba they forget about the real goal
    – Ewan
    Jun 17, 2015 at 6:32
2

When the team draws stories during the sprint planning, they should take their available skills into account. That means they might draw a backend-heavy story and leave a frontend-heavy story on the board if they have free backend capacity, or vice versa.

If nothing else, some programmers might find time for necessary refactoring.

If the imbalance persists for a long time, re-train or change the team.

Improve this answer
4
  • surely you have to take stories off by business priority
    – Ewan
    Jun 17, 2015 at 6:28
  • @Ewan, I have to take both the business priority and the team capacity into account. Lower-priority items get pulled if the higher-priority items don't fit into the sprint. A trivial example: The stories are A (8 points), B (12 points), C (1 point), D (1 point) in order ABCD and the team velocity is 15. The team can pull A, it cannot pull AB, but it can pull ACD. So ACD is it despite the fact that B outranks C and D. The team might even ask for permission to do BCD. The same applies if specialist skills are in short supply and there is no time to re-train the team.
    – o.m.
    Jun 17, 2015 at 14:58
  • i think that is counter to scrum. If a task is too big you should split it. Your method potentialy leaves tasks skipped for ever
    – Ewan
    Jun 18, 2015 at 18:17
  • Stories should have user value. Sometimes you can't divide them any more without creating user-value-less fragments. If the problem persists, increase the velocity per sprint by adding people or time. If it is just temporary, bear the pain for a time and get better.
    – o.m.
    Jun 20, 2015 at 5:40
1

If you have zero or very little backend development (or vice-versa), for all practical purposes, you treat that person like you would if she went on vacation or worked on another project. A particular sprint gets the total story points adjusted.

From a management perspective, you could treat this as an opportunity to cross-train people with pair-programming. If cross-training is one of the goals of this project, then count both developer's time/points. You'll have a more accurate way to plan a project that involves cross-training.

Improve this answer
2
  • We have a similar number of both front-end and back-end devs, however, the problem is, that when we have an upper limit of how many scrum points we can take per sprint, it seems that that number shouldn't apply. Because if there are more more tasks for front-end let's say, the back-end developers would have less work to do. It usually results in running out of tasks mid-sprint for either of them.
    – Zappateur
    Jun 15, 2015 at 13:46
  • 1
    @Zappateur - I would say you have 2 separate projects with 2 different teams. Then your implementation of Scrum will be a better fit. It can be difficult to adopt a methodology that is dependent on applying a related group of practices.
    – JeffO
    Jun 15, 2015 at 14:53
1

Yes, one should divide the tasks by work area expertise. This will allow for accurate resource and project/sprint planning. Let's say after story point estimation you have 100 front end points and 50 back end points over the course of the next few months of 2 week interations.

If this were the case, at a very high level one would need to finish equally:

  • 2 front end developers and 1 back end developer OR
  • 1 front end developer and 1 Generalist (Front/Back) OR
  • 1 front end developer and 1 back end developer (part time - 50%)

Story point estimation is the first step. The second is planning out resource assignments, work streams + dependencies.

Every project is different and stocked with people with different skill sets. There are few "full stack" developers out there that are good doing the UI front end all the way back to the back to the database. Even within a general techlogy like .Net there are specializations like ASP.NET MVC, WCF services, Entity Framework, etc. So, take in the developers skill sets into account when planning out the sprints from the backlog and there will be efficient utilitzation of resources across the board.

Improve this answer
2
  • hmm its generaly bad to split the team rather than cross train.
    – Ewan
    Jun 17, 2015 at 6:29
  • @Ewan - I agree cross train would be good, however, in many cases that is not possible or feasible because of time or cost constraints. Ideally yes, resources should be interchangeable.
    – Jon Raynor
    Jun 17, 2015 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.