Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This
This chapter is from the book

Favor Feature Teams

When I first began to consult for a certain California-based game studio, its teams were organized around the specific elements and objects that would exist in the video game it was developing. There was a separate team for each character. There were weapons teams, a vehicle team, and so on. This led to problems, such as weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player.

On more traditional, corporate projects, we see equivalent problems when teams organize around the layers of an application. For example, a typical early-stage mistake for the project whose architecture is shown in Figure 10.4 would be to have four teams: a rich client team, a web client team, a middle-tier team, and a database team. Creating component teams such as these leads to a variety of problems including

  • Reduced communication across the layers
  • A feeling that design by contract is sufficient
  • Ending sprints without a potentially shippable product increment
Figure 10.4

Figure 10.4 A typical three-tier architecture.

If structuring teams around the layers of an architecture is the wrong approach, what's better? Rather than organizing around components, each team on a project can ideally be responsible for end-to-end delivery of working (tested) features. A feature team working on the application shown in Figure 10.4 would, for example, work across all layers of the architecture. It might develop one feature that involves the database layer, the services tier, and the rich client user interface. In the same or next sprint, it would develop a feature going across the web client, services tier, and database tier.

There are many advantages to organizing multiteam projects into feature teams:

  • Feature teams are better able to evaluate the impact of design decisions. At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members' learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?).
  • Feature teams reduce waste created by hand-offs. Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.
  • It ensures that the right people are talking. Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.
  • Component teams create risk to the schedule. The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team's work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.
  • It keeps the focus on delivering features. It can be tempting for a team to fall back into its pre-Scrum habits. Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum's focus on delivering features in each sprint.

Use Component Teams Sparingly

Although you should strongly favor the use of feature teams, there will be occasions when creating a component team is appropriate. A component team, as I'm using the term here, is a team that develops software to be delivered to another team on the project rather than directly to users. Examples of component teams include a team developing an object-relational mapping layer between the application and the database or a reusable user interface widget team.

It is important that a component team still produce high-quality, tested, potentially shippable code by the end of each sprint. However, the new capabilities created by a component team are usually meaningless on their own. Think back for a moment to the examples I just gave. The object-relational mapping layer developed by one of the component teams is of interest to end users only through the context in which it is used by feature teams. But what about the team developing the reusable user interface widgets such as custom drop-down lists, data entry grids, and so on? These are certainly of interest to end users, right? Yes, but again only within the context of other features. An end user is not interested in a new data entry grid until it is embedded onto a page or screen.

Build Components Only As Feature Teams Ask for Them

Because the work of a component team is delivered to another team, it is those teams who usually act as the product owner for the component team. If your team needs deliverables from my team, then you will act as the product owner to my team. As such you will have all the responsibilities of a good product owner. At the start of a sprint, you will need to help prioritize what I work on. At the end of the sprint you will accept or reject it, providing feedback to me on what has been produced.

It will be hard for you to prioritize my work and provide feedback on it if my team is working far in advance of yours. Because of this, a component team should not develop new capabilities until one or more feature teams is ready for them. When a component team works far in advance of what feature teams need, they resort to guessing at what capabilities are needed next. All too often this results in components or frameworks that are not usable by the feature teams. All new capabilities, including those built by component teams, should be developed within the context of externally visible functionality.

Rob was the senior developer on a component team developing an object-relational mapping layer that would be used by many of the 15 feature teams on the project. Rob's team was initially tasked with choosing between developing this technology in-house or using a commercial or open-source product. Members made the questionable decision to build it themselves. Anxious to prove the correctness of this decision, Rob and team tried aggressively to get ahead of the needs of the feature teams. Rather than working closely with one or more feature teams, Rob's component team made some big guesses about the grand design. For two months (two sprints) members didn't deliver anything to the feature teams. After the third month, when they finally delivered an initial version, it did not meet the needs or expectations of the feature teams.

What Rob's team should have done instead was work very closely with the feature teams and add new capabilities in the context of the features being delivered by the feature teams. This would have forced a much closer collaboration between the component team and the feature team, increasing the chances of delivering what was needed. Rob's team could have, for example, delivered only the ability to write fixed-length text data to the database in the first sprint. Feature teams who received that capability would not have been able to write numeric data, dates, and so on to the database. And they would not have been able to read any data. But, the feature teams could have done one thing—write fixed-length text data—and from that could have provided feedback to Rob and his team on the usability of the component.

Perhaps the best way to ensure that a component team hears the feedback it will need to create useful functionality is to staff the component team temporarily with people from the feature teams. A developer assigned to a component team who knows he will soon be moving back to a feature team will be more likely to make sure the work of the component team will be usable.

Deciding When a Component Team Is Appropriate

Whenever possible, form feature teams rather than component teams. I like to start out with the assumption that all teams on a multiteam project will be feature teams. I'm willing to back away from that assumption, but I only want to do so in the face of evidence that forming one or more component teams will be in the best interest of the product. I suggest considering a component team only when most of the following statements are true:

  • The component team will build something that will be used by multiple feature teams. If a component will be used by only one feature team, have that feature team build it. This ensures that the new capability is built within the context of that team's needs and expectations, which makes the implementation more likely to be used. Even when a component team will build something useful to multiple teams, a better strategy is often to have one feature team build the functionality it needs and then have subsequent teams refactor and generalize the functionality as their needs arise.
  • Using a component team will reduce the sharing of specialists. On some multiteam projects, some highly specialized disciplines are shared across many teams. Although some sharing of specialists is usually necessary, too much of it can be detrimental as the specialist's time becomes too fragmented. You may want to consider creating a component team if doing so will make more manageable the extent to which specialists are shared across many teams.
  • The risk of multiple approaches outweighs the disadvantages of a component team. If we choose to build a shared component or service by having multiple feature teams contribute to the effort, there are two related risks to be aware of. First is the risk that each feature team implements a different solution to the same problem. Second is the risk that the feature teams each build on top of what prior feature teams have done but do so without a cohesive vision. These risks could be great or small, depending on what shared functionality is being built. When the risk of multiple approaches is high, a component team is a valid option.
  • It will get people talking who might not talk otherwise. People tend to talk more with those on their team than those outside their team. This is true even on a Scrum project. In fact, it may be especially true on a Scrum project because team members on Scrum projects come to identify so strongly with their teams. You can use this to your advantage by creating teams from people who need to work together but who might not naturally talk to each other. If past experience shows that a project's artificial intelligence programmers do not talk often enough, this can help justify the short-term use of a component team, as long as there are other reasons for doing so.
  • You can see an end to the need for the component team. A component team should not linger around forever, like my in-laws after the holidays. The team should develop the functionality it has been pulled together to create and then disband as soon as possible. When first forming a component team, it is not necessary to know when it will disband; however, you should have some idea of either how long it will exist or what will be delivered by the time the team has fulfilled its purpose. Because a component team is a deviation from the ideal of having all feature teams, you should be reluctant to create a component team that looks as though it might exist forever.

While acknowledging the occasional benefits of using a component team, I want to stress again that the vast majority of teams on a large project should be feature teams. Wes Williams and Mike Stout have described what happened at Sabre Airline Solutions when beginning with component teams.

  • Stories weren't complete from a user perspective. Teams were working on different features at different times with different acceptance criteria. There was a lot of rework coming back into the system. Teams were blaming each other for incomplete functionality, failing builds, test, etc. In hindsight...the teams should have been structured along functional or feature lines. (2008, 359)

Who Makes These Decisions?

Ideally, the team makes decisions about how it is structured. If the team is to be trusted with solving the problem of how to build the product, it seems appropriate to trust it with the decision about how to structure itself to do so. However, though team members are accustomed to making technical decisions, they usually do not have a lot of experience making team organization decisions. So, initially the team may not be in the best position to design its own structure.

I've introduced Scrum to hundreds of teams. One of the things I've noticed is how frequently someone's initial exposure to Scrum results in an opinion like, "Scrum sounds wonderful for our company, and it will be great for all the other groups but not mine." Architects add, "After we do the up-front architecture, I can really see how this will help the programmers and testers." User experience designers say, "After we've done the up-front usability research, I can really see how this will work for the architects, programmers, and testers." Testers take the initial view, "It will be wonderful to have everyone working so closely together and then handing off to us for a big round of integration testing."

If we ask team members with these common initial mindsets to design the structure of their multiteam project, it shouldn't surprise us when they come back with plans for an architecture team, a programming team, a user experience team, and a test team. Of course I'm generalizing, but the tendency to think this way is so prevalent that it will be tempting to organize that way as well.

Initially, then, it is likely that functional managers, project managers, ScrumMasters, or those driving the transition to Scrum will make the decisions about how to organize the teams. These decision makers should solicit nonbinding input from their teams, especially from team members with past experience with Scrum or other agile methodologies.

What's Right Today May Be Wrong Tomorrow

An important thing to remember when selecting an appropriate team structure is that no team structure is forever. If the current team structure is impeding a team's or project's ability to use Scrum, that issue should be raised during an end-of-sprint retrospective. You don't want to continually change team structures, as team members need time to jell, but if the current structure is clearly wrong, change it.

As team members gain more experience with Scrum, it will be appropriate for them to become more involved in team structure decisions, including which teams are needed, whether each is a feature or component team, and who should be on each team.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020