1

Our team consists of 4 full-time developers and occasional outside help. The developers maintain several different applications and do not all share the same skill set. I understand that scrum teams should be cross-functional, but in this case they all do the same general kind of work on the same general family of applications. There is some coupling between the applications, but not enough to make the developers interchangeable or consider the applications as "tiers" for the purpose of vertical slicing. The developers are essentially one- or two-man teams who know something about one another's work, but not enough to do it themselves.

How can the team agree on a common baseline or point of reference for estimating story points, when a one-point story on application A might not necessarily be half as big as a two-point story on application B? Should these developers even be considered a single scrum team?

Improve this question

2 Answers 2

Reset to default
0

Ideally as you said, you'd want the team to all be cross functional, all capable of working on any story and can swarm together when stories are blocked. In reality though, team members with different skill sets do exist, more frequently than you would expect.

In this instance, you want to agree what a '1' is for application A, requires similar effort as a similar story for application B. Same with a '2', and a '3' etc. At the end of the sprint, compare the stories completed, and ask the team, for this story for application 'A', we've estimated this as a '2'. And we've estimated this as a '2' for application B. Do you guys agree it's of a similar size? And so on, you can then save these stories for future reference as to what a '1' is for application A and another one for application B, and so on.

Even if the team work on specific areas/application, i would still be encouraging the team as a whole to estimate each story. The others should still have an understanding of what's being worked on, and may even be able to provide input/suggestion for application b, from their own experiences with application a.

Improve this answer
1

The reason for doing story point estimates is to help the team work out its velocity and from that its capacity for future sprints.

In your situation there are a number of factors working against the value of using story points. Firstly you mention that the team has occasional outside help. This outside help will impact on the team's capacity and velocity calculations. Secondly, it sounds like the work being brought in to the team is developer specific (or specific to pairs of developers).

The ideal solution would be to make the team more cross functional. If that is not possible then you may be better off thinking of the team as a number of work streams and estimating on them separately. For example, you could say the team has a capacity of 10 story points for application X and 15 story points for application Y.

Perhaps it would be worth considering having developers pair in an attempt to knowledge share?

Improve this answer
1
  • Cross training is an eventual goal, we just have to make enough time for it instead of putting out fires. Thanks for the answer.
    – Pedro
    Commented Aug 21, 2015 at 18:01

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.