Is team in Scrum feature team?

Feature team gains popularity, but the difference between feature team and cross-functional team is still confusing to many people. Surprisingly, I failed to find good reference to clarify it, thus I decide to write one.

1. Does Scrum require feature team?

If you read Scrum Guide, the below defines the (development) team.

"The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of 'Done' product at the end of each Sprint."

And it is clear that team is cross-functional.

"Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment."

However, it is not clearly stated whether it is feature team (vs. component team). This creates lots of confusion about whether cross-functional team implies feature team, and whether they are the same thing.

2. Does SAFe require feature team?

In my previous articles and presentations, I mentioned that SAFe did NOT require feature team, though it might still recommend it, it is not part of essential SAFe. One friend in the community argued with me that SAFe also requires feature team. His view was, as Scrum is used at team level in SAFe, and Scrum requires feature team, therefore, SAFe requires feature team. His argument has relevance to the same confusion - does Scrum require feature team?

If you read SAFe, the below defines the (Agile) team.

"An Agile Team consists of a small group of dedicated individuals, who together have the skills necessary to define (elaborate and design their component/feature), build (implement their component/feature), test (run the test cases and validate the component/feature) increments of value in a short timebox."

It is clear that team is cross-functional. It is somewhat clear that component team and feature team are both possible.

3. Does LeSS require feature team?

In LeSS, the below rule makes it clear that LeSS requires feature team.

"The majority of the teams are customer-focused feature teams."

The root of the confusion

Back to Scrum, it uses "Increment of 'Done' product" when defining the team. The root of the confusion is from being unclear about what the product is. In SAFe, it uses "increments of value". It does not help much to clear the confusion as it is not clear what value is either.

The question of "what the product is" sounds trivial but deserves deeper thinking. LeSS states, "When starting a LeSS Adoption, one of the first things to clarify is what your product actually is."

The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product.

  • If you define your component as product, the requirement on the component becomes feature.
  • If you define your platform as product, the requirement on the platform becomes feature.
  • If you define your "product" as product, the requirement on the "product" becomes feature.
  • If you define your solution as product, the requirement on the solution becomes feature.

The feature-ness is a continuum!

This is nicely illustrated by feature team adoption map in LeSS. In my view, the more precise name should be cross-functional feature team adoption map, as there are two dimensions - cross-functionality and feature-ness.

Does it mean that the whole distinction of component team and feature team is meaningless? Not really. It means that the distinction is contained by what the product is.

In LeSS, there is a rule regarding what the product is.

"The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred."

Clarify what the product is, and form feature team to deliver Done product increment.

Read more



ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai