Is there any formula to define team size for small project. I had read fibonacci sequence number formula for rating. So can we apply some logic to define teamsize? I mean we have two subprojects in a big project. What is ideal way to distribute manpower? Any reference related to same topic is welcome.
Add a comment
|
7 Answers
I think there can't be any formula. The size of the team can depend on experience and skill of particular members. For example I have a friend who can deliver 4 times more and better quality code than many good programmers I know.
Another thing is that 9 women won't bore a child in one month, so increasing size of the team won't solve all problems you may encounter.
If both projects are interesting maybe you could let people choose on which they want to work.
I would also recommend two things: sit together and communicate, communicate, communicate.
answered Feb 15, 2012 at 9:04
-
1I would not use skill level as an input. I would base my estimates on "average" skill. This is because the highly skilled team you think you will have may not be the team you end up having. You need to assume attrition and replacement with average people because average is what you will most likely get; after all, that is the definition of average. Feb 15, 2012 at 16:15
-
2I don't agree. You definitely have impact on your team choice. And you can align it while running the project. I can't imagine working with average people. For me average is bad when talking about software development. Feb 16, 2012 at 19:43
-
Think about the performance curve. Likely, it is a normal distribution. The curve itself suggests that most of us fall between zero and two sigma from the mean. This mean, when you are sifting through resumes, most of the candidates are average. Sometimes, you will get lucky and get one or two really high performers. Also, do not forget the notion of regression to the mean. Extreme performance is not often or likely to be repeated. So plan if you want using stellar resources, but you are betting on what you will not likely get. Feb 16, 2012 at 19:52
-
And I am not suggesting that you hire average. Go find and build a great team. We all try to do that, not just in SW development. But PLAN for average. You are building into your plan contingency when you do that. If you best resources get hit by a bus on their way to work, you will have runway to cope. Feb 16, 2012 at 19:56
-
1To some point I understand your point, but I would rather plan for the team I have now. You can't plan for a team you don't know. It's guessing instead of planning. And when talking about performance curve - 2 sigma gives you 95% from the whole scale, so you can get people really bad, or really good. Feb 17, 2012 at 19:54
Do not look for a formula. A formula will yield a single result. But an estimate is a range of possible results, over which a probabilistic distribution resides. For example, for task A, the size of your team can be a range from 4 FTEs to as high as 10 FTEs. The right answer for this task at this time lives somewhere in there. Staff experience and availability, environmental issues, luck, time of the year, etc., are all random variables that will favorably or unfavorably affect performance, none of which you can fully control or control at all, all of which will disallow you to arrive at a more deterministic value.
This does not mean, of course, you would staff 4 to 10 people. You have to choose. Risk management and your risk appetite play a heavy role in this decision. If you are confident, get close to 4. If you are unsure, climb.
How do you arrive at the estimate? Bottom-up, top-down, expert input, historical data with parametrics if you have it, and SWAG. Iterate it until everyone is nodding their head.
answered Feb 15, 2012 at 16:11
There is a fact in management that when you have more than 8 to 12 people around the table; a consensus is impossible. So if an organization try to reach a deal with 70 countries around a table (like for global warming for example), it is simply imposible to find commun grounds. To my point a view, I would never go over 7 people. It is better to have a number like 3, 5, 7, 9,... If there is a vote, it will not end up as tow sides equal. The best teams I have been in were 5 people team to organize an even; and 3 to deal with a minor issue. You can start small and add co-workers along the way if it is needed.
Welcome to PMSE, Abhijit!
I was discussing about this very same topic with a more seasoned manager here.
As you might see in some answers I share here in PMSE, I'll put another question that might help you to reach your solution (this one, based on some PMBoK tips; PMI masters, please correct me if I'm wrong!):
Have you already applied a WBS into your project to understand clearly what's this project about in details?
Have you already done some estimates (in man/hours) for each sub task in the project?
Have you already realized how many of these sub tasks can be done in parallel (a activity sequencing diagram could help you on it)?
Having the answers for these questions, you'll have a better picture of where you could allocate better your resources.
Notice these tips applies basically if you clearly know beforehand what has to be delivered.
Bottomline: There's no magic formula to give you the answer. There's a topic around PMSE that Joel Spolsky highlight it in a very objective manner (if someone knows the topic, a link here would be nice). You first need to clearly understand what needs to be done to define who / when it will be done.
Success!
answered Feb 15, 2012 at 15:11
Cost and duration of the project; this will determine what size of design team to employ.
Nature of the project/how many task are characterised within a given project's work.
Level of expertise of some project team leaders. If a team leader is very skilled, he or she will require a few helpers to work with him or her.
TL;DR
There is no one fixed formula that fits all frameworks and use cases, but there are definitely rules of thumb for agile frameworks, as well as some general guidelines for more traditional methodologies. In almost all cases, managing intra- and inter-team communications turns out to be the biggest constraint on team size, regardless of framework.
Agile Teams
It's generally recommended that agile teams contain around 7 members, plus or minus 2. Currently, the "Development Team Size" section of the Scrum Guide recommends 3-9 developers, exclusive of the Product Owner and Scrum Master.
You then scale the number of teams as required based on the number of related product backlogs in your project. The number of teams (and therefore team members) has more to do with how you parcel out the top-level Product Backlog than anything else, because in agile frameworks the variable constraint is scope, rather than cost or schedule.
Non-Agile Team Size
Non-agile projects are actually harder to answer this sort of question for, because they aren't generally structured for incremental delivery or a true team-based approach. A naive approach is to base team size on the man-hours needed to complete a project within the scheduled time frame, but as the saying goes, "Nine women can't make a baby in one month."
The optimal team size will vary greatly based on your industry and project, but in general a project will base its team sizes on the following elements:
- Specialized skills required at various points throughout the project lifecycle.
- Labor costs to deliver each defined milestone or WBS package.
- The number of team members a given team needs to deliver a specific work package.
- The number of separate or interdependent teams needed to deliver each work package.
- Margins for shifting resources in and out of the project.
- Expected turnover or attrition on the project.
- Man-hours required to meet the release schedule.
Because non-agile projects are usually based on a fixed schedule with a well-defined work breakdown structure, the team or teams needed are generally based on each work package and resources may roll on or off the project during the project's lifecycle.
However, even within traditional projects where team size isn't deliberately limited, a pragmatic constraint is the number of communications channels within a team and between teams. For example, a team of 35 people has 595 duplexed communications channels, while 10 teams of 7 people each would have 2,415 channels if the teams on the project are interdependent.
Even with rigorous (and often stifling) communication controls in place, keeping communication channels to a manageable level is probably a bigger constraint on effective team size than anything else. Project runtime, schedule, and budget will also have an impact on the ideal team size for a given project, but the communications plan becomes ever more important as the size or number of teams go up.
answered Apr 10, 2017 at 1:24
Assuming you're talking about a real team, that is a group or skilled and reasonably motivated individuals willing to cooperate with each other, the idea is to have - or at least start with - a reasonably small group, the smaller the better.
Scrums, for example, suggests to keep a team between 3 to 7/9 people, Jeff Bezos refers to the same principle with the 2 Pizza rule: "if a team couldn’t be fed with two pizzas, it was too big".
Why is that?
- More people means more person-to-person connections to look after, with this number growing exponentially. 7 people means 21 potential "connections" to look after, while 12 means 66 connections and so on...
- More people means more coordination effort
- More people means less social pressure, which could lead to less engagement (see: social loafing)
- Having more people makes stability harder, and that impacts predictability
A good article explaining this is: https://blog.bufferapp.com/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done
