7

We are used to create multiple sub-tasks for each user story and provide each sub-task with an estimate in hours and assignee (back or front-end).

With the following outcome:

  • Total estimated time needed in hours for user story divided over back and front-end
  • The availability of both back and front-end developers can be taken into account when user stories are placed in sprints
  • Developers are scheduled accordingly in Harvest Forecast based on their availability and back or front-end role

Despite, we are unable to provide an accurate estimated time. That is why we want to adjust our project management:

When we apply all this, we will most probably achieve a more accurate total estimate for a sprint and plan a feasible amount of work in a sprint based on the velocity.

We only have one problem. If we no longer use sub-tasks for the estimation, we also do not know how many hours a back or front-end developer needs to be scheduled in Harvest Forecast.

Hence the question: how to schedule back and front-end developers based on story points?

Related:

Improve this question
3
  • 2
    Schedule them for 40 hours a week each. Estimate projects in weeks times people, not task breakdowns. In short, be less granular to improve overall accuracy.
    – Todd A. Jacobs ♦
    Aug 10, 2018 at 19:19
  • @ToddA.Jacobs thanks! But what if it turns out that it is 70% back and 30% front-end?
    – Bart van Kleef
    Aug 10, 2018 at 19:28
  • 3
    If you want the benefits of agile estimation, don't fall prey to the 100% utilization fallacy or do individual estimation. Estimate work for the team as a whole.
    – Todd A. Jacobs ♦
    Aug 10, 2018 at 20:57

2 Answers 2

Reset to default
8

If I've interpreted correctly, your Question is how to convert Story Point estimations for User Stories into time-estimations for each individual developer.

My answer?

Don't.

The only possible reason I can think for why you would need individual estimates is for individual KPIs (Key Performance Indicators). Which, in my experience, are themselves harmful.

Instead, you should estimate for the Team. Treat the Team as a cohesive whole. Rather than taking Developer F 1 day and Developer B 2 days, the story takes the Team 2 story points. (Which you can then convert to time estimates for the Team, as I believe has been answered here before).

From your comment:

But what if it turns out that it is 70% back and 30% front-end?

This smells to me of the 100% Utilization Fallacy. So it turns out to take 70% back-end and 30% front-end... so what? That means the front-end developer(s) can spend more effective use of their slack time that Sprint. Maybe they can pair up with the back-end developer(s) in order to become T-shaped.

Improve this answer
8
  • Thanks, very enlightening! The reason is to use developers as efficiently as possible across multiple projects (in case of 70% back and 30% front-end) and so give the customer value for money, I could be wrong?
    – Bart van Kleef
    Aug 10, 2018 at 19:59
  • 2
    @BartvanKleef See the 100% utilization fallacy. You should be optimizing for throughput of tasks, not time of developers.
    – Sarov
    Aug 10, 2018 at 20:59
  • @BartvanKleef I’d caution against spreading the same person across multiple projects as well. There’s a huge cost to that kind of context switching and also inevitably ends with two projects fighting for 70% of the same person’a time. That results in a miserable workplace and burn out.
    – RubberDuck
    Aug 11, 2018 at 0:06
  • @BartvanKleef: What would you do if most projects are 70% back and 30% front for the next month? Send half your front-end developers with unpaid leave?
    – Bart van Ingen Schenau
    Aug 11, 2018 at 7:27
  • @BartvanIngenSchenau good question! We have some on-call (0-hours) employees. Or we place them on our own, side projects instead of customer. Never unpaid leave.
    – Bart van Kleef
    Aug 11, 2018 at 7:45
3

An approach I have seen done successfully is as follows.

The team estimates each backlog item in story points. The whole team estimates and they agree on the story points figure based on relative sizing.

The story points done in previous sprints is used to calculate the velocity of the team. This provides a guide to the capacity of future sprints.

In the planning meeting the team pulls stories from the product backlog until they have reached their capacity. For example, if the team's velocity is 30 story points, they would add stories to the sprint backlog until they reach close to 30 story points.

Next, the team looks at the highest priority story in the sprint backlog and breaks it down in to technical tasks. They do hour-based estimates on the technical tasks and note if they require a specialisation (e.g. front-end developer or back-end developer).

The team then uses the same approach on each of the remaining stories on the sprint backlog. As they are doing this, the Scrum Master tracks the hours for each specialisation. If they notice that one specialisation is getting overloaded, they tell the team. At this point the team can either:

  • Remove any stories from the sprint backlog that have not yet been broken down in to technical tasks
  • Look at the top of the product backlog and see if there are stories they can swap in to the sprint that creates a better balance of work for the various specialisations

This ensures that no specialisation becomes overloaded in the sprint.

It is worth noting that a better long-term approach is to ensure that team members have T shaped skills. If team members can do both front-end and back-end development work then they can:

  • Be much more flexible with the types of stories they bring in to sprints
  • Worry less about team members being under or over worked
  • Spend less time estimating
Improve this answer
1
  • Thanks for sharing! This seems to me the right approach to convert story points in estimations for user stories for back and front-end if you want to.
    – Bart van Kleef
    Aug 11, 2018 at 9:24

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.