Chapter 3

The Talent and the Timing

IN THIS CHAPTER

Structuring the scrum development team

Excelling at backlog estimation

Defining done

Benefiting from estimation techniques

The development team sits at the core of scrum projects. The primary focus of the product owner and the scrum master revolves around making sure that the environment is as ideal as possible for the development team to reach maximum productivity. In this chapter, you find out how a development team is organized and therefore able to best contribute to the scrum team.

After you have your team roles, vision, and roadmap in place, the next step is to begin to estimate the amount of work for each requirement. The development team begins by estimating the effort involved in high-level requirements. Here, you create a starting point for future reference. You establish the numerator (product backlog total)/denominator (average velocity) relationship that gives you the estimated number of sprints necessary to complete all, or a target portion of, items in the product backlog. This chapter shows you how these high-level estimates can be achieved quickly and accurately.

The Development Team

In Hollywood, actors and singers are referred to as “the talent.” They’re the ones who get on stage and do the job. Everyone else facilitates this process, because when the talent is successful, everyone is successful. Think of the development team as the talent. Retaining that talent as one of the byproducts of a good scrum implementation.

The development team is the talent responsible for creating and developing the actual product. They drive the how and the how much. In other words, they determine how they will develop the requirements and how many they can do in any one sprint. They are dedicated to one project at a time, cross-functional, self-organizing, and self-managing.

The development team is intentionally size-limited to around six members, plus or minus three. Optimal development team size is small enough to remain nimble and large enough to complete significant work within a sprint. This size allows for a self-sufficient and self-organizing group with a diversity of skills, yet it’s not too big and unwieldy. Keep in mind that for each new member, the lines of communication increase geometrically. With more than nine development team members, you can’t have a self-organizing team. Under a waterfall model, this issue is masked with a project manager, who is responsible for coordinating all the communication. Scrum doesn’t have the overhead cost of too many lines of communication or a project manager.

Although six people, plus or minus three, is a manageable and efficient size, the key factor is self-encapsulation. Is the team able to elaborate the requirements, design them, develop them, test them, integrate them, document them, and have them approved? Have single points of failure been eliminated (that is, at least two people can do any one skill)? Is the total size no more than nine people? If all three answers are yes, you have a good-size, cross-functional development team. Whereas a product owner must be decisive and a scrum master must have clout, a development team member must be versatile, intellectually curious, and predisposed to sharing. No prima donnas are allowed. Development team members’ fires are lit with building and creating.

The uniqueness of scrum development teams

In many ways, the scrum development team is the opposite of a traditional team. In scrum, development team members are going to develop cross-functional skills. They’re part of the goal-setting process, and, as a team, they have complete control of how they do their development. Additionally, credit is taken as a team.

Dedicated teams and cross-functionality

As mentioned previously, development team members are dedicated to one project at a time. Not making your development team switch back and forth between projects, which is known as thrashing. You want them to focus each day on the current sprint’s goal. Whether functional management chooses the team members or someone else does, a diversity of skills is sought after so the team has all the skills they need to be successful (they’re self-encapsulated). This leads us to the next point: cross-functionality.

People don’t necessarily start out being cross-functional; they grow into this state. Start with a team of diverse talents and then organically build that team toward being individually cross-functional. Ideally, you want every developer to be able to do everything. This isn’t always possible, but you at least want every developer to be able to do more than one thing and for every skill to have more than one person. Becoming cross-functional is a process, but it prevents bottlenecks in work delivery.

Whatever your business or organization, the facts remain: People go on vacation; they get sick; they take on new roles and jobs. One day, they’re there next to you, and the next day, they might be somewhere else. In traditional projects, when a key development team member goes on vacation, the project goes on vacation. You’re forced into delays as you wait for that person to return or (in the case of attrition) until you recruit and mobilize another person.

In scrum, you strive for cross-functionality in your development team. In this way, you eliminate that single point of failure. If one development team member comes down with the flu or is deeply involved in another task, someone else can take his place and get the job done. Cross-functionality also has these benefits:

• It allows for diverse input on development for optimal solutions.
• It enables pair development (which is described later in this section) to ensure higher quality.
• It’s one of the best ways to increase your primary skill. Learning an associative skill exposes you to other ways of thinking about your primary skill.
• It allows people to work on various things and keeps the work interesting.
• It can produce high-quality work delivered in the shortest amount of time without external dependencies.

Several ways exist to create cross-functional individuals from cross-functional teams:

• Don’t use titles. Encourage an equal playing field. Doing so stimulates junior developers to get up to speed faster, and senior-level skills increase because senior people don’t want to be outdone by young, hungry talent. A lack of titles also emphasizes skills over a fixed hierarchy, thereby encouraging skill development. Informal status still exists, but now it’s based on skills.
• Do use pair programming. Commonly used in software development practices such as Extreme Programming, pair programming can be used by a development team to develop any type of product. Two developers work together on the same piece of functionality. Developer A is tactically developing (cutting code, for example), while Developer B is free to think strategically about the functionality (scalability, extensibility, risks, and so on). They switch these roles throughout the day. Because these developers are working so tightly together, they can quickly catch errors. Developers stay more on task and make fewer errors as they’re pair programming, and the result is an overall shorter timeline.

• Do use shadowing. Again, two developers are working together, but in this case, only one does the work while the other watches and learns.

  Shadowing also increases product quality. Note that visibility and performance are correlated: Increase visibility, and you generally increase performance. The working developer doesn’t want to take a lazy shortcut in front of the learning one, and the learning one will ask those smart “dumb questions.” Explaining something improves your own knowledge of it, and vocalizing something uses a different part of your brain and improves functioning. Finally, ownership is reinforced if you’re teaching and explaining.

Self-organizing and self-managing

The key word is ownership. Self-organizing and self-managing teams develop ownership in what they do. With a scrum development team, whole team ownership is part of what creates such efficiency and success.

Think of this example: How can you be assured that a professional sports team will give 100 percent? The answer is that the team gives 100 percent because they would lose if they didn’t. The visibility and acknowledgment of their hard work increases drive.

Visibility and performance are directly correlated. Increase performance by increasing visibility.

One technique sometimes used is to have two (or more) development teams. Synchronize their sprints so that the sprint reviews happen at the same time on the same day. Then invite an executive to come to both sprint reviews randomly for a few minutes and have her ask at least one question before leaving. Each development team knows that its performance will have executive visibility, and all teams want to look good. Historically, they may not have been given credit for the work they did. Now they can produce a product that they can be proud of. They’re on stage, getting all the credit. This is hugely motivating and increases drive and buy-in.

Ownership and, therefore, accountability are increased in a scrum development team in the following ways:

• The development team is directly accountable for the deliverables that they create. This isn’t always easy on them because visibility brings intrinsic pressure to perform, but this visibility also creates ownership.
• Cross-functionality creates ownership because there isn’t any “my job” versus “your job.” Everything is our job.
• Because the whole scrum team is held accountable, individual performance is increased. Everyone wins as a team, and everyone contributes to the success of every sprint.
• The development team actively participates in creating the sprint goals and demonstrating the working functionality during the sprint review.
• The development team is responsible for tactical status reporting every single day. In less than one minute of administration per day (see the burndown charts in Chapter 4 of Book 5), the organization gets a level of tactical status reporting that it’s never had before.

Development teams perform best when they’re stable. Feed them projects and give them what they need to do their best possible work. Every time you switch members on your team, it takes time to stabilize again. Protect your development team to nurture good dynamics.

Cognitive consistency theory describes humans’ tendency to seek out information, beliefs, and stimuli that are consistent with current beliefs and attitudes. In scrum, if development team members have a voice, and if they have buy-in and control, they strive harder to achieve their work-related goals. They try to find consistency between the ownership that they created and their future output.

Co-locating or the nearest thing

Many people have forgotten what it’s like to work with a co-located team and to experience the increased production involved. Most people appreciate the concept but may not understand the underlying principles. Here are a few benefits of a co-located team:

• Increased speed and effectiveness of face-to-face communication, especially through kinetics, voice tonality, facial expressions, and so on.

  The value of face-to-face communication shouldn’t be underestimated. Albert Mehrabian, PhD, and professor emeritus of psychology at the University of California-Los Angeles, proved the following:

  • 55 percent of meaning is conveyed through body language and facial expressions.
  • 38 percent of meaning is paralinguistic (conveyed by the way we speak).
  • 7 percent of meaning is conveyed in the actual words spoken.

  These statistics alone are a whopping case for co-locating your development team.

• Ease of using simple tools for planning and communicating, such as whiteboards and sticky notes.
• Ease in immediate clarification of questions.
• Understanding what other members are working on.
• Ease in supporting other team members in their tasks.
• Cost savings due to decreased lag times and fewer misunderstandings that lead to defects or wasted work.

When co-located, your product owner and development team have access to each other all day every day. All sort of banality is exchanged, and it’s tempting to think that this might be wasteful. However, it’s during these exchanges when the really good work gets done. Little things aren’t actually little; they’re differentiators, and they’re the things that matter. Quality needs input, and input needs access. When access is high, great things are possible.

Sometimes, outsourcing is the only viable solution for your company or organization. If this is the case, do it with both feet. Co-locate the entire scrum team. Your development team needs an available product owner, so send one to the outsourcing location to work directly with the remote scrum team. Or develop a local product owner, even if he has to start as a product owner agent (see Chapter 1 in Book 5). The increase in quality and efficiency far outweighs the cost of the product owner.

Getting the Edge on Backlog Estimation

In the product roadmap stage, the development team does a high-level estimate of the amount of work entailed in the project. The practical value of this estimation process doesn’t come into play until the sprints start (see Chapter 4 in Book 5), but this initial estimation sets a mark from which future estimates may be calculated. The development team does the estimating because only the people who do the work should be estimating the effort of the work. The backlog is the list of work presented in story form for the team. The stories are developed in iterations.

These backlog estimation techniques aren’t requirements of scrum. They’re common practices that scrum practitioners have found useful in the field.

The product roadmap is the start of the product backlog. What’s on your roadmap is what you will begin developing. So how do you take all those items on your product backlog and with any degree of accuracy estimate the work involved? A few common practices are used depending on the situation. Before you look at these estimating techniques individually, it’s important to understand what you’re trying to achieve.

Your Definition of Done

If you ask the members of a scrum team what they expect to see when a requirement is done, you get as many answers as there are team members. So before starting a project, scrum teams define what done means with a definition of done. Until you have consensus on this definition, estimations will be based on bad data.

As described in Chapter 2 of Book 5, for each requirement within a sprint, you complete the following stages of development:

• Requirement elaboration
• Design
• Development
• Comprehensive testing
• Integration
• Documentation
• Approval

This definition of done needs to be specific, refined, and focused on what it means to do these things to completion to achieve the level of quality that you’re striving for in your project. Consider which environment the product or service needs to work within and at what level of integration to be considered done. “Works in the development environment,” for example, is probably a bad, loose definition of done.

Consider these four factors in your definition of done:

• Developed: The product has been fully developed by the development team.
• Tested: The development team fully tested the product to make sure that it functions in the required environment without any glitches.
• Integrated: The product has been fully integrated within the product as a whole and any related systems.
• Documented: The development team created whatever documentation is needed. Just remember that the goal with all things agile is “barely sufficient.”

When you’ve come up with your definition of done, write it out on a white poster board and tape it on the wall. You’ll always have it right in front of the development team and product owner. You can call it in-your-face documentation. No cover sheet, no table of contents — simply the lowest-fidelity way that communicates and makes the information the most visible.

In your definition of done, consider not only the development but also the depth of testing and documentation that you might need. You might consider which tests must pass the following:

• Unit
• Functional/system
• Performance/load
• Security
• User acceptance

Also consider what documentation you need:

• Technical
• User
• Maintenance

Each of these testing and documentation points may differ between the sprint level and the release level, though the sprint-level definition of done should include everything necessary to release. You also may have organizationally specific items that you want to include. It’s your choice. The point is to have a clear definition of done that’s defined by the scrum team for all to work by.

A release occurs when a set of marketable features is released outside the scrum team. This could happen several times during a sprint, at the end of each sprint, or after a series of sprints. These requirements may be released into the market and to the users, or they may go to internal or external stakeholders for real-world use and feedback.

A regular sprint entails completing the development, testing, documentation, and approval of items in the sprint backlog. However, before you do a product release, other activities may be needed (such as performance and load testing) that the development team wouldn’t have access to in a regular sprint. Therefore, sometimes scrum teams have a release sprint just before the release itself to allow these additional tests to be addressed. The key is at the end of every sprint, the requirements must work and be demonstrable. You can test and tune for scale in the release sprint, but the requirements must work every sprint.

Common Practices for Estimating

Estimating the effort involved in developing product backlog requirements is an ongoing process. (Chapter 2 in Book 5 discusses product backlog refinement.) For example, you could do estimations for 30 minutes at 5 every evening before team members go home. This way, at the end of the week, you’ve covered lots of ground and will be ready for each sprint start. Some teams don’t like to develop on Friday afternoon and do product backlog refinement then.

Teams are likely to refine their estimates at three levels as part of the process of breaking the requirements down for sprint-level execution. Depending on your product, you may include more. Your estimate refinement usually goes in this order:

1. Product roadmap
2. Release planning
3. Sprint planning

The development team is responsible for estimating the effort required to fully build the requirements. The scrum master can facilitate the process, and the product owner can provide clarification, but the decision is made by developers doing the actual work.

You should use relative estimating in lieu of precise (absolute) estimating, because in many situations, it’s much more feasible. If you’re asked to look out the window and say how tall the neighboring building is, how precise would be your reply? Very — it’s 950 feet. How accurate would be your reply? Not very. Why? Because you honestly have no idea; you gave it a wild guess. But if you’re asked to look at two nearby buildings and say which one is taller, barring some vision problem, it’s guaranteed that you’ll give the right answer. Using relative sizing is an effective way to overcome the difficulty we humans have in making absolute estimates.

Fibonacci numbers and story points

The Fibonacci sequence is an excellent sizing technique for relative estimating. With Fibonacci, if something is bigger, you get an idea of how much bigger it is. The last two numbers in the sequence are added to create the next number. Fibonacci numbers look like this:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so on

As the numbering progresses, the distance between the numbers increases. This technique is used to acknowledge the lesser degree of accuracy in predicting larger chunks of work.

A story point is the Fibonacci number assigned to an individual requirement (that is, a user story).

Initial high-level requirements are estimated at the product roadmap level:

• The development team understands that requirements with Fibonacci number estimates from 1 through 8 can be brought into a sprint. This level of refinement usually results in a user story.
• Requirements with estimates numbered from 13 through 34 are those that you would let into a release but need to be broken down further before you would let them into a sprint. At this level of refinement, these requirements are called epics.
• Requirements from 55 through 144 are too big for a release but are estimable at the order-of-magnitude product roadmap level. These requirements typically reflect features.
• Requirements larger than 144 need to be broken down before the development team can give any semblance of an accurate estimate, so don’t estimate beyond 144. These may represent broader themes.

Whatever the Fibonacci number, only the highest-priority cards get broken down into sprint-level sizes (which shouldn’t be more than an 8). So, if you have a high-priority requirement with a 21 Fibonacci number assigned to it, it needs to be broken into smaller requirements before it can come into a sprint.

With the sizes established, you can apply a few techniques to estimate requirements:

• When you have shorter lists of requirements, you begin with estimation poker.
• When you have hundreds of requirements, you begin with affinity estimation (discussed later in this chapter).

In the estimation process with smaller projects, the development team begin as follows. The team sits down with their stack of requirements written on 3x5 cards. Then they pick a requirement that they can all agree has an effort level of 5. This creates a reference point.

They then pick another card and, based on the first one being a 5, ask themselves what number the next one would be. If it’s greater than a 5, is it an 8, a 13, or a 21? This process continues until a few representational sizes have been established.

Estimation poker

A popular way to estimate requirements is to use a variation of poker. You need a deck of estimation poker cards like the one shown in Figure 3-1. (You can find them at https://platinumedge.com/store/estimation-poker-cards). You can also download a poker estimation app for iPhone and/or Android by searching for Platinum Edge Estimation Poker in your device’s app store or make your own deck with index cards and a marker.

© John Wiley & Sons, Inc.

FIGURE 3-1: Estimation poker cards for estimating the amount of effort required in each requirement.

Because only the development team decides how much it will take to develop a requirement, only the development team plays estimation poker. The scrum master facilitates, and the product owner reads the requirements and provides requirement details, but neither of those two gives estimates. It goes like this:

1. The product owner reads a targeted requirement to the development team, including acceptance criteria.
2. The development team asks any questions and gets any clarifications they need.

3. Each member of the development team picks from his deck a card with his estimate of the difficulty of the requirement.

   The estimate is to accomplish the complete definition of done, not just to write code.

   Members don’t show anyone else their cards because you don’t want others being influenced.

4. After everyone has picked a number, the team members simultaneously show their cards.
   • If everyone has the same estimate, nothing is left to discuss. Assign the requirement that estimate and move on to the next requirement.
   • If differences exist in estimates, those with the highest and lowest estimates are asked to explain. Further clarification from the product owner is given as needed.
5. With increased knowledge, everyone picks a new number for that requirement by repeating Steps 3 and 4.

You can normally do up to three rounds of estimation poker for each requirement to get the core assumptions on the table and clarified, and at that point, you usually have the estimates in a tighter cluster of numbers.

If all developers agree on a single number after three rounds, you’re ready to move on to the next requirement. But you won’t always have all developers in agreement on a single number after three rounds. At this point, you can go on to a consensus-building technique called fist of five.

Fist of five

A fast and efficient method of reaching consensus, fist of five can be used on its own or as an addendum to estimation poker. The purpose of fist of five is to quickly find an estimate that all team members can support (see Figure 3-2).

© John Wiley & Sons, Inc.

FIGURE 3-2: Fist of five is an efficient way of finding consensus in many situations.

Perhaps when you tried estimation poker, some team members have given a requirement a 5, and others have given it an 8.

It begins with the scrum master holding up the requirement card in question and saying, for example, “How comfortable would you be with this as an 8?” Each development team member holds up the number of fingers associated with their level of comfort. If everyone is holding up three, four, or five fingers, it’s settled.

If some developers are holding up one or two fingers, as in estimation poker, the outliers would be asked to explain, and further information would be garnered if necessary. Fist of five would be performed again. Continue with this process until all team members can give the number at least a 3 (which is, “I don’t love it, but I can support it”).

With fist of five completed and requirements estimated, you’re ready to move to release or sprint planning. They’re covered in Chapter 4 of Book 5.

Affinity estimating

Estimation poker and fist of five are effective methods of establishing consensus in small projects. But what if you have several hundred requirements on the product backlog? It could take days to complete. This is where affinity estimating comes into play.

Instead of beginning with Fibonacci numbers, you begin with a more familiar concept: T-shirt sizes (XS, S, M, L, and XL).

With affinity estimating, you first create several areas marked with each size and then place each requirement in one of the size categories. It goes like this:

1. Identify small tables to sort the cards.

   Label a table Clarify, and label other small tables for each of these size categories:

   • Extra-small
   • Small
   • Medium
   • Large
   • Extra-large
   • Epic (too large to fit into the sprint, given that six to ten requirements are the target for each sprint; more on this is in Chapter 4 of Book 5)

2. For each size category, give your development team 60 seconds to pick a requirement from the overall stack of requirements and place it on the corresponding table.

   This establishes the representational anchor for each size.

3. Each member of the development team grabs a stack of requirements.

4. Each member places each card on the table that they feel reflects its size based on the representational anchor for that size.

   As you can see, these are like T-shirt sizes. Each “size” will eventually correspond to a Fibonacci number:

   • Extra-small equals 1.
   • Small equals 2.
   • Medium equals 3.
   • Large equals 5.
   • Extra-large equals 8.

   Anything larger than an 8 needs to be broken down further before it can come into a sprint.

   Don’t let team members linger too long on their stack of requirements. Establish a timebox for them to work within, for example, 20 minutes for 20 cards. Timebox is a term that refers to the allotted time for an event or activity. If your sprints last two weeks, the timebox is two weeks.

   Figure 3-3 shows what the relationship between size piles and Fibonacci numbers looks like.

5. Have the development team members play something called gallery until all members agree on the sizes for each requirement. In gallery, the team members flip through all the cards on all the tables and provide feedback on only the cards that don’t appear to be on the right table.

   If one team member wants to move a story from small to medium, for example, check that the original person who placed it there doesn’t disagree. If the person disagrees, place that card on a separate Clarify table. Don’t get into extensive discussions just yet.

6. Invite the product owner to review for major disagreements:
   • If the product owner sees a requirement on the medium table that she thought would be a small, don’t waste any time discussing it. The development team ultimately gets to say the size of the requirement, and a one-size difference isn’t worth the time to discuss.
   • If you have greater than one table of difference between where development team members think a card should be placed and where the product owner thought it would be placed, put that card on the Clarify table. The development team may not have understood the product owner’s explanation of the requirement.
7. For cards on the Clarify table, play estimation poker (discussed earlier in this chapter).

© John Wiley & Sons, Inc.

FIGURE 3-3: Affinity estimating uses T-shirt sizes for story sizes and gives each one a corresponding Fibonacci number.

Within a relatively short amount of time, you’ve been able to reliably estimate the effort on hundreds of separate requirements. You’re ready to plan your first release and/or your first sprint.

Velocity

After you have Fibonacci numbers assigned to your requirements, you have story points to work from.

Chapter 4 in Book 5 shows how to plan both releases and sprints. To plan your first sprint, among those requirements that are between 1 and 8 story points, a scrum team determines a modest number of combined story points to work on. Then, at the end of the sprint, a scrum team looks at the requirements that were done to completion and adds their story points. The result might be 15, 25, or 35 story points. This is the development team’s velocity for the first sprint and starting input for a team determining how much it can accomplish in the next sprint.

Velocity is the combined number of story points that your development team completed in an individual sprint. It’s a postsprint fact used for extrapolation, not a presprint goal.

To accurately determine velocity, you need more than one sprint to find an average. Velocity follows the law of large numbers; the more data points you have, the better. At minimum, you need three data points to establish an optimistic, pessimistic, and most likely extrapolation of how many requirements will be done during the project. After you have these, you can tell stakeholders optimistic, pessimistic, and most likely estimates for how many of the highest-priority requirements on the product backlog can be completed within a project. Giving stakeholders this type of estimation range provides the level of detail they’re looking for while allowing some flexibility for the development team as they’re still getting into a development rhythm.

In the first few sprints of a project, the team’s velocity will usually vary greatly. It becomes more stable as the team gets into a development rhythm. Of course, changes in team members or sprint duration will introduce variability into the team’s velocity.

Velocity isn’t a goal; it’s a fact used for extrapolation. Higher numbers are not automatically better than lower numbers.

When story points are used, you’ll find that some teams are pessimistic in their estimates. Their numbers always come in high. Other teams are optimistic. Their story point total comes in low.

Consider that an optimistic team’s velocity is 15 and the estimates for the release total 150 points. It would take them ten sprints to complete the release.

If a pessimistic team’s velocity were 30 and the estimates for the release total 300 points, it would take them ten sprints as well.

Optimistic or pessimistic doesn’t really matter. Teams will generally be consistent one way or the other and therefore balance out in the end. This is the reason you always value a team’s velocity against itself, not against other teams. In fact, don’t even tell anyone what a team’s velocity is. Consider it an extrapolation system, not a performance system.

When you have a clear method of estimating the effort required to complete each requirement, and you have an average velocity established for the development team, you’re able to accurately predict the quantity of product that can be created within fixed cost and time constraints. You’re harnessing your variables.

Successful scrum teams need to share ownership of outcomes and value authentic transparency between the team and its stakeholders. Progress is visible to everyone.