• 3 replies
  • Latest Post - ‏2011-01-17T19:08:45Z by jruehlin
6 Posts

Pinned topic OpenUP Team Size Guidance

‏2010-11-06T12:50:59Z |
"OpenUP is a process for small, co-located teams. It can be used as-is but, if your team has significantly different characteristics, the process should be modified or extended to address those needs."

Does small mean a project size of under 20 team members for a duration of less than 25 months?

In applying OpenUP, can User Stories be used instead of Use Cases ?

It seems scenarios are not defined. Are they ever not used?

Updated on 2011-01-17T19:08:45Z at 2011-01-17T19:08:45Z by jruehlin
  • ScottAmbler
    158 Posts

    Re: OpenUP Team Size Guidance

    Size is in the eye of the beholder. Best definition that I ever saw for large team size was 20% bigger than what you've been successful at. So, one person might consider a team of 10 people to be large but another person consider it quite small.

    In my survey where I examined the effects of team size on success rates, see , I used the following definitions: small was 1-10, medium was 11 to 25 and large was 26 or more.

    • Scott
  • BruceMacIsaac
    19 Posts

    Re: OpenUP Team Size Guidance

    In applying OpenUP, user stories can definitely be used in place of use cases.
    In fact, the latest Rational Method Composer practices library includes a practice for story-driven development, which can be used as an alternative to use cases.
    Rational Method Composer customers can be download the latest library here:

    Bruce MacIsaac
    Manager Rational Method Composer Practices/RUP/OpenUP
  • jruehlin
    12 Posts

    Re: OpenUP Team Size Guidance

    The size of a "small" team was a big debate we had when writing OpenUP. There's a lot of variation of opinion, and we never agreed on a firm number. In my research on team sizes, I came to the conclusion that a small team was 5 or fewer people. Six people, even experienced people, are bigger than a small team.

    This is mostly due to the communication overhead required by members of a team. After 5 people, the overhead starts to grow asymptotically. I haven't found any research on what happens to a team at this point, but it's a good bet that something different starts to occur! Every person added to a team after the 5th person raises the communication overhead significantly and in a non-linear way. It's likely that after 5 people, the nature of how people communicate need to change because they can no longer scale the techniques they used when they were a smaller team.

    Many Agile techniques depend on teams that can take advantage of lower communication overhead. This includes things like creating fewer artifacts. You can get away with this for a while, but since you can't communicate with 8 people as efficiently as you can 3, you need to have formalized artifacts and reviews when teams get bigger. And "bigger" happens quickly.

    There's also the issue of team members "hiding out" versus taking responsibility for the team. Research indicates that a team size of 3 is ideal for maximizing the amount of work done (because people can't hide out) by each individual. Performance per team member goes down as more members are added after that.

    So I wound up with 5 being the largest sized team that can be considered small. 3 or 4 is better. In my experience, OpenUP out-of-the-box will work best for small teams defined in this way. Of course, it can be scaled to larger teams by adopting other practices or customizing OpenUP practices.

    • Jim

    Jim Ruehlin, IBM Rational Software
    Jazz Jumpstart Team, Processes and Practices
    EPF Committer