Theme Scoring

You can use theme scoring to compare user stories or entire projects against one another. In this technique you identify a set of criteria that will be important in prioritizing. Each item is assessed on a relative 1-5 scale against each criterion and the priorities are determined.

Theme Screening

Like theme scoring and relative weighting, this technique can be used to prioritize user stories or projects against one another. The simplest of the three prioritization techniques, theme screening starts with you identifying a baseline item. Each other item to be prioritized is compared to the baseline item for a set of factors that will determine priorities.

I’ve wanted to make some of these available for a long time so it’s nice to finally be able to do so. The first two tools we’re making available are a velocity range calculator and a relative weighting worksheet.

Velocity Range Calculator

The velocity range calculator takes as inputs at least five recent sprints and then tells you the range which corresponds to a 90% confidence interval around your velocity. Plans created with this 90% confidence interval will be more likely to be accurate than plans created with a point estimate of velocity. This technique is described in Succeeding with Agile.

Relative Weighting Worksheet

The second tool is a relative weighting worksheet. Relative weighting is a prioritization technique that can be used for items on your product backlog (or for comparing entire projects). I teach this technique in Certified Scrum Product Owner classes and wrote about it in Agile Estimating and Planning.

More to Come

You can find the tools in the new tools section of the Mountain Goat Software website.

I’ll have more tools to announce in about a week.

Unfortunately, many projects schedule too much time for teambuilding exercises and discussions too early in the project. This is a common and dangerous mistake, as shown by research from Professor Lynda Gratton and her coauthors, as published in the MIT Sloan Management Review.

Guiding these diverse teams to success requires some counterintuitive management practices. In particular, team leaders should focus on tasks at the early stages, rather than on interpersonal relationships, and then switch to relationship building when the time is right. (Gratton, Voigt, and Erickson. “Bridging faultlines in diverse teams.” MIT Sloan Management Review, Summer 2007, 22–29.)

Though this research suggests that the early focus should be on tasks, I do not mean to suggest that product owners or ScrumMasters should be assigning tasks to developers. Rather, I mean that these leaders should emphasize the need for the team to make demonstrable progress even in the early sprints. The problem with an early emphasis on relationship building is that it encourages less-than-ideal subgroups to form. Any large group will inevitably split into subgroups. If these subgroups are allowed to form too early they will form around surface-level attributes—Americans, Swedes, C++ programmers, Java programmers, female database engineers, male programmers, and so on. As Gratton and her coauthors write, “Simply put, in a team’s early going, the more people interact with one another, the more likely they are to make snap judgments and to emphasize their differences” (26).

What we’d like to do is defer relationship building until team members have learned more significant things about each other, such as specific skills, competencies, approaches to work, and so on. This is done through early emphasis on progress rather than relationship building. The subgroups that form at that time will be based on the mutual need to work together to develop the product. To develop a particular user story from the product backlog, you and I need to work together. In doing so we learn each other’s skills and specific competencies. I come to know you not just as a Java programmer but as a Java programmer with a real passion and strength for automated unit testing. You find that I am not just a DBA, but one who is strong at optimizing SQL statements.

Teams with subgroups formed around compatible skills, attitudes, approaches to work, and so on are less likely to lead to a later breakdown in trust than subgroups formed on superficial attributes (such as American, Swede, programmer, tester, and so on). Think back to one or more troubled teams you were a member of. Odds are that conflict on those teams was of an us-versus-them nature based on superficial attributes: this office versus that office, programmer versus DBA, Linux fanatics versus Windows fanatics. When teams feel an immediate need to make progress, those types of subgroups do not have time to form.

After a team has worked together for a few sprints, shift the emphasis toward relationship building by incorporating more social activities and shared downtime into the sprints. A team needs to have a sufficient amount of shared experience before social activities and relationship building can be useful. But when that has been achieved, “instilling confidence in the team and creating opportunities to socialize at that point helps the development of new abilities and allows the team to grow” (29).

I want to be clear that I am not saying that no time for socialization should be included at the start of a project. Seeding visits and whole-team, in-person get-togethers at the start of a project for its initial release planning can be very useful. Three points are key here:

• First, the project should start with intensity and a focus on early demonstrations of progress.
• Second, the entire “budget” for socialization should not be spent in the first couple of sprints.
• Third, early social activities should tie into the work of the project, such as bringing a team together for release planning.

Attendees at our courses have always been able to claim Professional Development Units (PDUs) for our courses, but becoming a Registered Education Provider through the PMI allows us to offer Category 3 PDUs. This makes PDU reporting and tracking easy for attendees at Mountain Goat Software courses. At the end of each course, we provide you with a code that has been registered with the PMI and that authenticates your PDUs.

You can see a complete list of our public agile and Scrum training courses on our website. Courses are also offered for onsite delivery.

We’ll continue to ship via UPS and the US Postal Service both domestically and internationally.

Also, if you didn’t catch the previous announcement, we now have two styles of Planning Poker cards–our branded ones with the mountain goat photos and unbranded ones with a cool burndown chart design. Those cost a bit more but that’s because we sell the branded ones at a bit of a loss. You can check them out on the Mountain Goat Software Store.

The problem here is not that the team’s estimate of seven months is right or wrong. The problem is that the estimate was turned into a commitment. “We estimate this will take seven months” was translated into “We commit to finishing in seven months.” Estimating and committing are both important, but they should be viewed as separate activities.

I need to pick up my daughter from swim practice tonight. I asked her what time she’d be done (which we defined as finished swimming, showered, and ready to go home). She said, “I should be ready by 5:15.” That was her estimate. If I had asked for a firm commitment—be outside the facility by the stated time or I’ll drive away without you—she might have committed to 5:25 to allow herself time to recover from any problems, such as a slightly longer practice, the coach’s watch being off by five minutes, a line at the showers, and so on. To determine a time she could commit to, my daughter would still have formed an estimate. But rather than telling me her estimate directly, she would have converted into it a deadline she could commit to.

Don’t let your estimates become commitments. Remember the difference between an estimate and a commitment and keep the two activities separate, educating management and customers as necessary. I talk much more about agile estimating and committing in my new book, Succeeding with Agile.

When I saw Derek walking toward me at the conference, I was thrilled. I had first met him a year earlier when I taught a class at his company. I had been back a handful of times, and I always enjoyed talking to him, but we hadn’t talked in three months. I thought this would be a good chance to catch up. As we said hello, I could tell something was really bothering him, so we sat down to talk. Derek told me that at his team’s sprint review the week before, the team had decided to ask him to resign as their ScrumMaster and to leave the team. He had done so and was looking around within his company to find another Scrum team to join. But the shock of being asked to leave had not yet worn off.

Although rare, Derek’s situation is not unheard of. The question of whether the team has the authority to remove someone from the team is a common topic. Commonly referred to as “voting someone off the island,” removing a team member is not an action to be considered lightly. Before such measures are taken, efforts should be made to address problems that lead some or all team members to feel that they might be better off without one of their members.

A team alone should not have the right to remove someone from the team. As I detail in Chapter 12 of Succeeding with Agile, self-organization does not occur in a vacuum. The right preconditions must be in place for self-organization to occur. Individuals then self-organize within boundaries established by the organization. This is referred to as the CDE model, which says that for self-organization to occur there must be a container that bounds the individuals, some differences among them, and transforming exchanges.

Chapter 12 also makes the point that leaders within the organization exert influence on the self-organizing team by adjusting its containers, differences, and exchanges. For example, over time and through attrition a team might have become too homogeneous. An astute product owner, functional manager, or even ScrumMaster might counter that by adding two new team members with radically different backgrounds, skills, decision-making styles, or so on. Doesn’t it seem possible—likely even, in this example—that a team might have a knee-jerk reaction and vote the new, nonconforming individuals off the team, negating the work of the leader who deliberately added them? Ultimate authority for team composition, therefore, must reside with the leadership of the organization. Those leaders should listen, of course, when team members say they think they’d be more productive without a member. But, team members should not be allowed on their own to remove someone from the team.

The Agile Journal article includes a sidebar by Laurie Williams and Kenny Rubin, my partners on this project. Laurie is currently heading up an effort to refine the questions that form the survey. We could use your help.