Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 0 down vote favorite

Looking for a systematic method for estimating and comparing the success factors of sprint configurations based on:

  • Team Size
  • Sprint Duration
  • Number of Stories
share|improve this question

2 Answers

up vote 4 down vote accepted

You should embrace the idea of continuous improvement.

As far as team size goes, Scrum calls for a team size of no more than 7 people. There are some roles that you need to fill, as well. You're going to need a ScrumMaster who is not part of the development team, a Product Owner who can be the voice of the customer and maintain the product backlog, and you're going to need at least one or two developers, so there's a team of 3-4 people right there. Depending on the project and teams involved, you might need some other people - graphic designers, usability experts, system administrators, quality specialists, marketing and sales - who might or might not be integrated with the development team.

For the number of stories per sprint, this will normalize over time. Prioritize your backlog, then take what your team considers a reasonable number of stories off the product backlog for the sprint backlog. After your first sprint, you have a velocity that can be used to compute the number of stories for future sprints. Compute your velocity using story points finished, the duration of the sprint, and your human resource utilization. As people leave or are added to the team or you adjust your sprint length or people have their time split between multiple projects, pick the number of stories appropriately. Address issues during your sprint retrospectives.

The Scrum handbook (PDF) says that sprints are less than 1 month in length and are measured in weeks. 2-3 weeks are typical. If that doesn't work for you, adjust. Be sure to plan your sprint accordingly, in terms of available resources over the course of the sprint, the duration, and previous velocities.

share|improve this answer
I double checked the calculations provided in Jeff's blog post that appear to come from "Rubin, Howard (Ed.) A Metrics View of Software Engineering Performance Across Industries" - and based on my calculations the median team of seven ppl's cost/function result was $435 per function, and the 14-person team's was $130 per function. What am I missing? Thanks! – blunders Dec 15 '11 at 17:57
1  
@blunders I didn't run the numbers until just now, and I'm still not sure how he's getting those values. However, this isn't the only study that demonstrates that a team size of 5-7 people is optimal for productivity. – Thomas Owens♦ Dec 15 '11 at 18:22
+1 @Thomas Owens: Point is that unless a study releases data, sources, and methods it is subject to the very issue I just pointed out, as I'm sure you're aware of. That said, I'm not looking for studies, but a means to optimize success factors within a sprint's configuration. Thanks for the confirmation that Jeff's numbers appear to prove the opposite of what he claims. – blunders Dec 15 '11 at 18:45
1  
@blunders He only provides a small sample of the study. In order to learn more, you should read Ruby and Howard's publication. If it's a good publication, it will provide the information you are looking for. As far as not looking for studies, I think that's the wrong approach - scientific studies (especially about team size and team dynamics) are exactly what you are looking for. – Thomas Owens♦ Dec 15 '11 at 18:53
+1 @Thomas Owens: Attempted to find the study after running across what appears to be an error, though I was unable to find it. That said, I respect your advice to referenece studies, but that is not what I'm looking for in this case. Cheers, and thanks for all your effort - unless a better answer is posted, I'll select your answer as is, since I do believe it's reflective of the standard view within Scrum. – blunders Dec 15 '11 at 19:04
up vote 3 down vote

Scrum is a simple "inspect and adapt" framework, not a methodology.

Team Size, Sprint Duration and the rest should be adapted to your particular case. You adapt it by constantly inspect your processes thanks to retrospectives and reviews.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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