Our team’s home page shows a graph of metrics displayed as a series per team member, displayed over time. The graph is designed to highlight the scores of distinct team members changing over time, as well as the overall state of the team. As we meet to reflect on how things are going, perhaps during a retrospective meeting, we note the behaviours which have helped or hindered achieving our goals and we assign points (positive or negative) to team members responsible.
When you meet as a team to think about what went well and what can be improved, it can be useful to pick out just one or two behaviours which you want to change over the next iteration. If a member of the team has set a strong example of how you want to behave - lets say “Only one item returned from QA”, it’s worth creating a Menu item for this behaviour and assigning the item’s points to the person in question. You can choose an arbitrary number of points to allocate - choose something which reflects how important this behaviour is in relation to the others listed on your menu. Over time you can reduce the points allocated to a menu item without affecting the score already accrued by team members.
Aside: Points have no inherent meaning except in relation to each other, and are only useful to illustrate trends over time. If that sounds familiar, then you too may use Story Points (or T-shirt sizes) to estimate user stories for Agile iteration planning. For this reason, you can’t directly compare one team’s score against another (and to do so would be counter productive). Instead, you need to look at the rate of change over time, which illustrates if a team is improving (or not) over time.
When you pick a score from the menu, you get select team members to score negatively or positively against the particular behaviour. Note that there’s no sliding scale - you can score the points agreed, or not at all. This is similar to the Agile concept of “Done” - a pre-agreed threshold which establishes a well understood goal.
You can also approach the scoring process from the other perspective - scoring one team member against all the behaviours currently in the score menu.
Note: if you approach scoring from the perspective of the team member, don’t fall into the trap of allocating the same number of menu items to each team member in an attempt to placate individuals.
Of course, not everyone likes to be structured about things. If establishing a menu of fixed behaviours seems overly draconian, you can simply allocate points with a custom description, unlinked to any menu item. This approach can be more effective when you’re working with an experienced team who have a lower threshold for “mind-control” ; )