content top

The Scrum Team

The Scrum Team

The Scrum Team is made up of the people who actually work on Product Backlog Items during a Sprint. In a software context, this group is most often called the Development Team. In other contexts, the simple term Team is often used. The Scrum Master and the Product Owner, while part of the overall Scrum Team, may or may not be members of the Team working on PBIs. There is no Project Manager or Team Lead in Scrum. Everyone is simply an equal member of the Team.


In the original Harvard Business Review paper that inspired the creation of Scrum, “The New New Product Development Game,” Professors Hirotaka Takeuchi and Ikujiro Nonaka observed great teams were:

1. Transcendent: They have a sense of purpose beyond the ordinary. This self-realized goal allows them to move beyond the ordinary into the extraordinary. In a very real way the very decision to not be average, but to be great, changes the way they view themselves and what they’re capable of.

2. Autonomous: The teams are self-organizing and self-managing, they have the power to make their own decisions about how they do their jobs, and are empowered to make those decisions stick.

3. Cross-Functional: The teams have all the skills needed to complete the project. Planning, design, production, sales, distribution. And those skills feed and reinforce each other. As one team member that designed a revolutionary new camera for Canon described it: “When all the team members are located in one large room, someone’s information becomes yours, without even trying. You then start thinking in terms of what’s best or second best for the group at large and not only where you stand.”

People sometimes struggle with the idea of transcendence. Transcendence is the spirit of the team. The first Scrum team watched a video at the beginning of each Daily Meeting of New Zealand’s All Blacks rugby team. The energy from that team is palpable. They are united in purpose. The first Scrum team wanted to capture that spirit: the determination to crush any impediment; the spirit to celebrate every success; the goal of victory. That is team transcendence, whether on a sports team or delivering great products or services.

In the early 1990s Jim Coplien was invited to assess a project at the Borland Software Corporation. They were making a new spreadsheet program called Quattro Pro for Windows. The software had more than one million lines of code, took thirty-one months, and a team of eight people. That means each team member produced one thousand lines of code every week. That’s more code in less time than any team on record. (See Coplien’s paper in the Papers and Patterns tab.)

To figure out why the Borland team was so fast, Coplien mapped all the communication flows within the team—who was talking to whom, where information was flowing, and where it was not. This type of mapping is a classic tool that can be used to spot bottlenecks or information hoarders. The greater the communication saturation—the more everyone knows everything—the faster the team. Basically, the metric spun off by this type of analysis measures how well everyone knows what they need to know to get their work done. The Borland team still has the highest rating ever: 90 percent. Most companies hover around 20 percent.

What cripples communication saturation is specialization—the number of roles and titles in a group. If people have a specific title, they tend to do only tasks that match for that title. And to protect the power of that role, they tend to hold on to specialized knowledge. That is why Scrum only has three roles: a person is either a member of the Team, the Scrum Master, or the Product Owner. This can be difficult for traditional organizations, but it is critical to get the kind of productivity increases that Scrum can deliver.

Just as the number of roles impacts performance, the sheer number of people on a Team also has a dramatic effect. The Team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two, though the fastest teams usually hover around five. What’s fascinating is that the data shows that if there are more than nine people on a team Velocity actually slows down. Surprisingly, more resources actually make Teams slower.

In software development there’s a term called Brooks’ Law. Fred Brooks first coined it in his seminal 1975 book The Mythical Man-Month. Put simply, Brooks’ Law states “adding manpower to a late software project makes it later.” This has been borne out in study after study. Lawrence Putnam, a legendary figure in software development, made it his life’s work to study how long things take to make and why. His work kept showing that projects with twenty or more people on them used more effort than those with five or fewer. Not just a little bit, but a lot. A large team would take about five times the number of hours that a small team would. He saw this again and again, and in the mid-1990s he decided to do a broad-based study to determine what the right team size is. So he looked at 491 medium-size projects at hundreds of different companies. These were all projects that required new products or features to be created, not a repurposing of old versions. He divided the projects by team size and noticed something right away. Once the teams grew larger than eight, they took dramatically longer to get things done. Groups made up of three to seven people required about 25 percent of the effort of groups of nine to twenty to get the same amount of work done. This result recurred over hundreds and hundreds of projects. That large teams accomplish less than small teams do seems to be an ironclad rule of human nature. (See Slides tab.)

Too often there are tasks that only one person on the Team can do. This is common among beginning Scrum Teams. It needs to be addressed as quickly as possible. The reason is that if only one person can do the work, and that person is unavailable, the whole team grinds to a halt. People get sick, people change jobs; you can’t afford to have your organization held hostage by one skill set.

Good Scrum teams make sure that at least two people, and ideally more, can do any one job. The teams that solve this problem tend to increase their Velocity. The reason is that collective knowledge, not individual skill, is what improves team speed. Individuals can falter, yet if the rest of the team can carry on, their productivity doesn’t suffer.

Perhaps the best way to make sure your team isn’t limited is through pairing and cross-training. If there is only one person that can do a task, make sure the next time that task comes up they pair with someone while doing it so that person can learn. Encourage all of your people to cross-train in various skill sets, not only will you reap the benefits, but they will be more engaged and excited as they learn new skills.


Borland Paper on Teams 


Autonomous Team


Stable Team


The Scrum Pattern Language of Programing: The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Next Suggested Topic: Scrum Master    

Back to the Framework 

Read More

Scrum Master

Scrum Master

The Scrum Master is tasked with making Scrum work. They work intimately with the Team, sometimes as a member. Their primary task is to remove Impediments and guide the team in Scrum practices. The Scrum Master does whatever it takes to help the team succeed.

Scrum Masters are servant-leaders not managers. They play the pivotal role of making sure Scrum is practiced well. The Scrum Master is accountable for the Velocity and the Continuous Improvement of the Team.

The Scrum Master accelerates the Team’s Velocity by:

  • Removing impediments
  • Surfacing and implementing process improvements
  • Ensuring theTeam understands and adheres to best Scrum practices
  • Facilitating the Scrum ceremonies
  • Coaching the Team to self-organize and self-manage
  • Making sure the Team is cross-functional
  • Keeping the Team focused on a transcendent goal
  • Assisting the Product Owner to refine a ready backlog
  • Representing the Team to the rest of the organization
  • Protecting the Team from interruptions
  • Keeping Team morale high


Persistent people achieve success by continuing forward even when things are difficult.


Driven people are self-motivated and push themselves hard to achieve what they want.


People with a strong sense of service are constantly looking for ways to serve and help.


Good Listeners are able to listen intently to what people say and help people feel heard.


Catalysts motivate and inspire others to make things happen.


Enablers create the conditions for people to grow and develop for themselves.  Courageous people don’t let their fears dictate their actions.


Scrum Master  

The Scrum Pattern Language of Programming codifies well known Agile practices that have been successfully implemented many times.

Next Suggested Topic: Product Owner

Back to the Framework | All Topics

Read More

Backlog Item (PBI)

Backlog Item (PBI)

Product Backlog Items (PBIs) are the elements that make up the Product Backlog. They can range from specifications and requirements, to use cases, epics, User Stories, or even bugs and chores. Each PBI must have these qualities:

  • Description: What the goal of the PBI is.
  • Value: he Business Value of the PBI as determined by the Product Owner.
  • Estimate: the Team needs to estimate the relative effort it will take to move the PBI to Done.
  • Order: The Product Owner needs to prioritize PBIs by their relative value.

Together these qualities make up the Definition of Ready. Having a ready Backlog can double a Team’s Velocity. Ideally, PBIs reflect the needs of customers or stakeholders. A common way to incorporate the end users’ needs is to write the PBI in the form of a User Story.

Back to the Framework 

Read More

Product Owner

Product Owner

The Product Owner is the Team member who knows what the customer wants and the relative Business Value of those wants. He can then translate the customer’s wants and values back to the Scrum team.

The Product Owner must know the business case for the product and what features the customers wants. He must be available to consult with the team to make sure they are correctly implementing the product vision. Most importantly, he must have the authority to make all decisions necessary to complete the project.

The Product Owner is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list (Product Backlog) deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list (Refining the Backlog). The Product Owner is responsible for the product vision, the business plan, and the revenue or cost savings generated by the business plan. This person spends half of their time working with customers and stakeholders and the other half working with the Team implementing the Product Backlog.

The Product Owner is responsible for determining the highest-business-value lowest-cost items for each Sprint, i.e. developing ordering the backlog in a way that maximizes value, and delivering backlog in a Ready state at the beginning of each sprint.. The Product Owner is the only person who has full and final authority over the project. In multi-team programs, this one Product Owner may delegate work to a representive on subordinate teams, but all decisions and direction come from the top-level, single Chief Product Owner. An adequate Product Owner needs to meet these minimal requirements:

Knowledgeability: If the Product Owner does not know the market, the customer, the product, and the competition, the team will lose confidence in their leadership. This will lead to slow down and disagreement over priorities. It is not possible for a new Product Owner to know everything. They need help from management and the team to ramp up their capability. This needs to be built into their job description.

Availability: The best Chief Product Owner is often a business leader (like Steve Jobs). The Product Owner spends half the time working with the customer and the market and the other half working closely with the team. If the business leader has to be part-time, she or he needs a full-time Product Owner to do the day-to-day work. Failing to do this will lead to problems like the one described above. The customer will not like the result, and more work will need to be done. It is cheaper to hire a Product Owner than deal with the damage later.

Decisiveness: The Product Owner owns the final decision on the ordering of the Product Backlog. Failure to do this will cause priority conflicts and cut team velocity in half. It is cheaper to hire a new Product Owner than to let this happen. This means the Product Owner needs the confidence of the stakeholders (and the team). If they don’t have it, they can’t do the job.

Accountability: The Product Owner owns the business plan and is accountable for driving revenue (or whatever value your organization is producing). It is not helpful for a hyperproductive team to deliver many features if the revenue per point is minimal. The Product Owner should be measured on revenue per point and how much the revenue per point is increasing over time


Product Owner 

The Scrum Pattern Language of Programming :  The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Next Suggested Topic:  Product Backlog

Back to the Framework 

Read More
content top