2

My scrum team consists of developers who are experts in various fields. For example, we have two front-end and two back-end developers. Assume our velocity is 10. It seems that we can put tasks which sum of estimated story points is less or equal to 10.

We have task to do something on front-end side and this task estimated to 9 story points. As I mentioned previously, we can put this task to sprint backlog if there are no other tasks there but team velocity doesn't respect that front-end developers can complete up to 5 story points per sprint, so this sprint will overdue. How to use velocity in teams which consist of experts in different fields?

1
  • 2
    If you do not have a cross-functional team or are not working toward making your team cross-functional, you do not have a Scrum Team. From the Scrum Guide: Scrum Teams are self-organizing and cross-functional. Principles of Scrum are based on following the other principles, so you won't find any guidance in the Scrum framework for this.
    – Thomas Owens
    Dec 20, 2016 at 14:20

3 Answers 3

7

This sounds like a Scrum-but

As stated in the comments, you do not have a Scrum team if it is not cross functional.

Scrum Teams are self-organizing and cross-functional

Mixing front- and back-end developers does actually make the team cross-functional. Developers arent robots; no team is composed of entirely identically skilled members. It seems like the problem you're highlighting is that you can see that you won't have perfect utilisation through this sprint.

Velocity is not a perfect predictor of work, just a tool. If occasionally you don't get full utilisation then this will impact your velocity. If the team don't feel that they can achieve this 9 point story in the sprint then they should break it down into an achievable story and bring in something else so that they can remain productive.

Maybe the team has self-organised into a back and front-end divide because that solves the problem for most sprints. It's an obvious compromise because of scenarios like you describe, but despite that, it could still be the most efficient way to organise.

In terms of becoming more cross-functional, your team should look to do skills sharing. Techniques like pair-programming are often recommended for this. As you've already got two pairs it sounds ideal to pair a back-end and front-end developer together.

Any team member should be able to do any task. You don't have to be an expert to contribute. Look at open source as an example of changes being treated by their merits. Perhaps code reviews can be used to ensure the quality remains high throughout the entire codebase.

I have been in many different types of teams and consider myself a generalizing specialist.

1
  • 3
    The term "T-shaped developer" is another way of calling "generalizing specialist" developers.
    – Sklivvz
    Dec 20, 2016 at 15:39
1

Either create two separate teams/projects or just know that some sprints will be off on estimates when the tasks are heavy in one area over the other.

It seems as if you really have two different teams. Do everything separately when it comes to sprint planning. Where do you draw the line to separate a project or treat it as the same project? It's just a matter of perspective. One group could build a front-end app and another some sort of backend or service. Just because they're both building what could be called the Billing System doesn't mean they have to do everything together. Gather stories, keep both projects in synch and then go off on their own to build what they plan to during the sprint and track their own velocity.

If you want to keep the team together, you just roll with it. You're going to have to adjust the amount of work getting done for that sprint. Don't expect to get it exact. It's no different then having a developer unavailable during a major part of the sprint. These sprints that are low in productivity need to be identified, so future staffing and training decisions can be made. If this occurs once in awhile, no one is going to take any drastic measures to fix it. It's an opportunity to cross-train if the team is inclined. Many aren't.

One key to trying to estimate is not to look at too narrow of a task or slice of time. You're trying to estimate on average, what the entire team can accomplish during a sprint. Not all sprints are equal and those who get it perfect all the time are probably cheating. When the work is balanced across all skill sets, the team will be more productive. Many teams do not have a balance of talent. On a 4 person team, when the top developer is unavailable, don't count on getting 75% of the work done. You may not even get 50%.

0

Assuming the nine point story must be done, you have two choices:

  1. pull the story in and do your best. Perhaps the back-end people can help by doing the testing or documentation parts of the story
  2. split the story into smaller stories so that you can accomplish one story in this sprint and one or more in the following sprints.

Remember: story points and velocity are simply tools to help you plan. At the end of the day, your team must decide how to accomplish the work using the points as a guide rather than an immutable law.

Your Answer

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

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