"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?
ScottAmbler 120000HESD158 Posts
Re: OpenUP Team Size Guidance2010-11-10T15:25:30ZThis is the accepted answer. This is the accepted answer.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 http://www.ambysoft.com/surveys/stateOfITUnion201007.html , I used the following definitions: small was 1-10, medium was 11 to 25 and large was 26 or more.
BruceMacIsaac 120000D6HD19 Posts
Re: OpenUP Team Size Guidance2010-12-06T22:30:12ZThis is the accepted answer. This is the accepted answer.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:
Manager Rational Method Composer Practices/RUP/OpenUP
jruehlin 120000GMDQ12 Posts
Re: OpenUP Team Size Guidance2011-01-17T19:08:45ZThis is the accepted answer. This is the accepted answer.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 Ruehlin, IBM Rational Software
Jazz Jumpstart Team, Processes and Practices