Scrum Tool Home

Online Scrum Software Development Blog

Digg This! Post on Facebook! Post on Yahoo! Post on Reddit Post on Delicious Stumble This! Tweet This! Post on Google

Wednesday, August 18, 2010

Top 7 Requisites for Scrum Teams

By Laszlo Szalvay

One of the Scrum method’s biggest selling points is its capacity to yield hyper-performing teams. Of course, Scrum teams aren’t just your run-of-the-mill dev teams. There are certain requisites—seven of them, actually—which teams should adhere to if they’d like to see Scrum transform their group into a well-oiled machine:

  1. An ideal team includes seven members, plus or minus two. According to study, small teams work together best. Once a team grows to more than nine or shrinks to smaller than five, its ability to perform well as a team is greatly diminished.
  2. Teams are comprised of cross-functional members, including software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. By creating a team composed of individuals with backgrounds in a diverse range of disciplines, a spectrum of opinions, ideas, and experiences are represented in the group. Not only does this mean that all development activities can be performed by the group, it also means that multiple perspectives will inform difficult decisions.
  3. Team members should be located in the same room, called the team room. While a single location for the team won’t ensure success with Scrum, it helps a lot. When a team is able to work within the same, small vicinity, Scrum’s emphasis on communication and collaboration can be maximized.
  4. If teams aren’t located in a team room, they’ll need a Scrum tooling solution. When a team is dispersed geographically, however, a Scrum tooling solution is usually required to keep a team connected. In especially fast-paced development environments, a tooling solution may be necessary for collocated teams, as well.
  5. Teams negotiate work with the Product Owner. While the development team must complete the work negotiated in the sprint planning meeting, it has some say in the amount of work it takes on. The Product Owner will expect the team to take on as many story points of work as possible, within reason. (The team would reference its established velocity for previous sprints to negotiate how many story points would be reasonable.) The value of this process of negotiation is twofold. It protects the development team from becoming swamped with an unrealistic workload. It also manages the expectations of the Product Owner, who, in turn, can do the same for customers.
  6. Teams self-organize. Once a team has committed to its work for the sprint, it may determine how to complete those goals autonomously. That is, provided the team’s work is satisfactorily completed by the sprint’s end, it can choose how and in what order that work is completed. This allows natural leadership to emerge from within the team and empowers teams with the freedom to confront impediments with creativity and innovation.
  7. Teams’ work should meet ALL acceptance criteria. Most Scrum teams do not award partial credit. Even if 99 percent of a project is “done,” it will be rejected in the sprint review meeting if it fails to meet all the established acceptance criteria. Teams often discover the hard way that a project’s finishing touches are often the most time-consuming and labor-intensive.