Visualizing Retrospective Priorities

We tried a new retrospective prioritization/voting technique this week that worked really well. After we had generated and discussed all of our ideas for improvement, it was clear to me that there were several excellent ideas and it would be hard to use our regular voting technique to single out one or two. In fact, it seemed clear that there were several ideas that should all be done and were somewhat related. I decided to try a technique in order to visualize the priorities, grouping, and weighting of the ideas.

I drew a line on the whiteboard from the bottom right to the top left and put all the ideas we had generated in the middle of the board. I then asked the team to approach the board and move the items they believed would have the most impact to the top left and the least impact to the bottom right. Yes, I was a little worried about the priming effect of having everyone voting together but I decided to ignore my own advice this time.

After the post-it notes on the board 'settled into position', we held another brief discussion to confirm the position of the ideas. It was clear that there were several high impact ideas on the board that needed to be implemented right away and some interesting clusters formed at the top left. The position of the post-it notes also visibly identified the ideas that the team thought would have a lower impact and could be dealt with another time.

The final confirmation that this visualization of priorities was effective came later that day - the team met and started implementing their ideas.

P.S. Yet again the 'take it to the team' approach resulted in a better solution than the ones I had envisioned prior to the retrospective. #TeamGenius

Subscribe to Winnipeg Agilist by Email

It’s the system, not (and?) the people.

I live and work with two phrases in my head that are important to me:

“It’s the system, not the people” – Deming

 And, paradoxically:

“It’s all about the people” – a statement heard often at Protegra that we try to use to guide how we work together.

An event this weekend helped me to understand these seemingly contradictory ideas. My brother (as coach) and nephew (as player) are participating in the junior varsity (gr. 9/10) provincial basketball championships. Last night I was able to watch them play in the semi-finals and could see both of the quotes above at work.

“It’s the system, not the people”

After an exciting victory by my nephew’s team, I overheard a conversation between two neutral parties as they did a postmortem on the game. In their assessment they agreed that both teams were skilled, gave it everything that they had, and played with passion. The main difference between the two teams was that the winning team had a better defensive system – not better players, but a better system. While the opposing coach did his best to exhort his players to play smarter, take better shots, make better passes, avoid the red beads, and play harder defense, ultimately they were defeated by a better system. They didn’t lose this game because of “resources” (coaches, players and refs), they lost to a better system.

“It’s all about the people”

Let’s look at the game from another angle. It was my brother the coach (a person) who researched, introduced, and taught the system to the team. It was the players (people) who bought into and committed to playing within the system. Both the offensive and defensive systems used by the team are well chosen and effective because they depend on teamwork and collaboration. Their systems require all of them to act together – if one person steps outside of the system it breaks down. The systems do not rely on one or two heroes but on the team as a whole. The systems require people to learn together, improve together, and be engaged together. The systems are all about the people. A pretty neat life lesson for a group of gr. 10 boys.

So, yes “It’s the system, not the people”, and yes, “It’s all about the people.”

“We believe it’s all about people. We believe by systematically focusing on people, treating them as the heart of organizational systems, that success will follow for all.” – Protegra.

Subscribe to Winnipeg Agilist by Email

San Jose Budget Games 2013

"Whatever is the problem, community is the answer" - Margaret J. Weatley.

I've been reading some of Margaret's writings this week and her words have been ringing in my ears as I remember participating as a volunteer facilitator in the 3rd annual San Jose Budget Games on January 26. Somewhere close to 200 community leaders, politicians, city staff, and volunteer facilitators gathered to have conversations about the city budget priorities. This wasn't a typical town hall meeting where the city presents the budget priorities and community members gather at a microphone to voice their displeasure. Instead, 20 tables of 8-10 people gathered to play a version of Buy a Feature by Innovation Games. Through the game, each table was asked to wrestle with and agree on both where to spend the budget (more police? more library hours?) and whether or not to increase city revenues (increase sales tax? create a parcel tax?) to fund more initiatives. San Jose elected officials, police chief, fire chief, city clerks and others were available to answer any questions.

As a facilitator it was interesting to watch a diverse group of people talk to each other about priorities for their city. Here are a few observations that I found interesting:

• Though they didn't always agree, the game produced some great discussions.
• Disagreements at our table ended with increased understanding.
• The discussions were neighbour to neighbour vs. citizen to politician.
• I heard citizens talking positively about their city politicians ("I don't always agree with them, but I like their approach - they are serious about engaging us in helping making the city better").
• Many citizens were playing the game a second or third time - asking a community for help and then acting on their responses creates engagement and joint commitment.
• Relationships were built rather than fractured ... at a budget meeting!
• This approach to solving problems can create a better community, neighourhood, team, company, city, etc.

San Jose isn't the only group to start embracing a community approach to problem solving. I'm sure if you reflect on your own experiences you'll recall examples of community approaches producing excellent results. Wheatley describes several similar examples in her article "It's Time for the Heroes to Go Home" and in the agile community we've embraced this approach through self organizing teams and frequent retrospectives.

I don't know if I'll be able to participate in a future budget game, but I'll always be grateful to the city of San Jose and the Every Voice Engaged foundation (the non-profit arm of Innovation Games) for the opportunity to be involved this year. If we ever do this in Winnipeg, count me in.

Finally, along with this reminder to 'take it to the team', here are a few practical methods you can use to do so:

• Innovation Games
• World Cafe
• Retrospectives
• Lean Coffee

 (You can read more about the budget games in the Financial Times and Bloomsberg Business Week)

Subscribe to Winnipeg Agilist by Email

I don't know, but you probably do.

Sometimes, the best answer to a question is "I don't know, but you probably do". Let me explain...

I occasionally have the opportunity to speak at user groups or to groups of employees to introduce them to agile - what it is, why it is important, how to start, etc. The presentations vary depending on the audience but always end in an open question period to answer any and all questions about agile. I can usually provide an answer to most of the questions, but I try to use various strategies to draw answers from the audience instead of answering each one on my own. Many times, their answers are better or more convincing than my own. If I'm not sure of the answer, I *usually* tell them I don't know but point them to some resources that might help. However... sometimes I forget.

At a recent speaking engagement I was asked a question about how to apply agile principles to address specific operations and maintenance issues. I answered the question, but I'm pretty sure my answer was too vague and largely unhelpful - some useful comment about reducing wip I think ;). So, here is my attempt at answering the question again using both the principles and the knowledge of the group to solve the problem. Of course, that group isn't here, but hopefully this will help anyways (I'll be e-mailing this to them).

"Thanks for the excellent question! I don't know the answer, but you probably do. Yes, it is true that reducing wip will likely help improve your situation, but since I don't at the moment understand the specifics of your problem, let me give you a few ideas to try. You probably have or can start tracking some metrics of how long it takes maintenance and operational issues to be solved. Using this as a baseline, try a few experiments and measure their results. To determine what experiments to try, have regular meetings with your team and ask them a) what has worked well in the past, b) what hasn't worked well and c) what would they recommend. Based on those recommendations, pick one or two experiments to try and then measure the results. Over time, I'd bet that your team will be successful in solving this problem together."

Kanban Boards - What Restaurants and Agile Projects Have in Common

I recently finished reading the book "Influencer: The Power to Change Anything." Among other things, the book describes several influence strategies and one of them is to use physical things to promote the desired behaviour. To illustrate their point they provided a simple example that I'll summarize in the next paragraph before drawing similarities to how a kanban system can influence good behaviours for your team.

The 1940s saw an increase in people eating out at restaurants after the end of the war and a surge in growth and prosperity. During this time restaurants struggled to keep up with the demand and tension grew between wait staff and cooks. Orders were late or confused and customers were annoyed. Dr. William Foote Whyte was invited to help. His solution was to install a simple 50 cent order spindle - a basic kanban system that later evolved into the order wheel. Wait staff wrote their detailed orders on paper that were skewered onto the spindle and the cooks would fulfill the orders generally in a first in first out sequence. This simple system worked wonders and still exists today. Cook staff could clearly understand the priorities and requirements for the meals while still being allowed some flexibility to make the meals in an efficient order. Wait staff could detail the order expectations and gain a better understanding of when meals would be completed. For more of the story, you'll need to read the book (Influencer, pages 220-222).

If your organization is experiencing similar issues and frustrations between your customers and your IT staff, then implementing a simple kanban system like the spindle could be a first step to improving your results, communication and behaviour. If your requests are sized appropriately (think meals for individuals vs. meals for everyone in the restaurant), then your customers can decide which stories are important enough to put on the kanban board and put them on in the order they would like them completed. Use index cards or stickies with detailed instructions on them (acceptance tests) as a way of keeping the requests small. Keep the board small enough so that only a limited amount of requests can fit. As one request moves off the board, the customer gets to add another. Measure the average time it takes for a request to enter and exit the board so that your customers can understand how long it will take to complete an average request. Making this process visible in a physical and tangible way can help encourage communication and cooperation between your customers and your IT staff.

For another view of a simple kanban board and how it works, check out Henrik Kniberg's cartoon here: http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

If you are already doing some agile development but have not yet experimented with kanban, consider using a kanban board within each iteration. Our team had discussions today for how we are going to set up our iteration kanban board for a new project and here is the draft plan with 5 columns left to right:

• Iteration Backlog (limited to the points we think we can achieve in this iteration)
• WIP - Tests Defined (limit of 3)
• WIP - In development (limit of 5)
• WIP - Testing (limit of 3)
• Done (limited to the number of stories we can actually complete in an iteration)

This simple board helps improve communication and expectations between team members and stakeholders. It also encourages behaviours that we value - blurring of specializations, team cooperation, team ownership, and getting things to 'done'. Enforced wip limits will inevitably mean that developers will need to help testers/analysts and vice versa, and that one story has to move to done before a new story can begin. Also, a board that visualizes your process can increase ownership of the process and the results. I expect the columns and wip limits to change as we use our board but we find this mix of scrum and kanban to be valuable.

Want to receive future blog posts in your inbox? Enter your email address here. 

Team Ownership through the UX Design Studio Approach

A few weeks ago I was added to a new team that had already spent some time working on the technical challenges for the project but had yet to do much UX work. One of the first things the team asked me to help with was to create the User Interface design. I think what they expected was for me to ask some probing questions, go draw some pretty pictures in Visio or some other tool and then present (and dictate) the results. I've certainly taken this approach on previous projects. However, in this case I went to my agile improvement backlog and decided to try the Design Studio approach I had learned at Agile 2010 in a session by Todd Zaki Warfel.

The Design Studio approach is a team approach to UX design. When I first asked the team if they would consider doing the UX design as a team, they were surprised and delighted to be asked (cool!). I had high hopes for this approach because I was excited to see the results of using the collective imagination of the team to create a cohesive and well thought out design. Before I share the results, here are the details of this technique:

Prerequisites: You should have already created your initial backlog of user stories. Creating other artifacts like personas and user scenarios first would also be useful. In our case we had the stories and some scenarios, but no personas yet. You will also need to print out several 8up sheets like the one in the image below and bring along several pencils. You can download the 8Up here or create your own in Excel. 

Steps:

1. Gather team members for the exercise. Not everyone needs to participate, but you should have willing participants from each role including developers and client.
2. Decide on a focus for your UX design. This could be a specific release, user scenario, or some grouping of user stories.
3. Hand out 8up papers and pencils to everyone on the team.
4. Ask everyone to create 6-8 sketches of the different pages/screens in the app (see tips below).
5. Once you start, tell them they only have 5 minutes to complete their 6-8 sketches.
   • You could tell them this before, but it seems to help crystalize their thoughts when they hear this.
6. After 5 minutes, review each set of drawings:
   • Each person has 3 minutes to pitch their drawings to the team.
   • The team then has 2 minutes to identify 3 things that worked and 2 things to change.
7. Repeat steps 3-6 until the team reaches a consensus on the design.
8. Once your design is complete, keep the final sheets as your UI reference model.
   • You won't likely need to transfer this to Visio or any other tool. The model should contain enough information and brief notes so that you can develop straight from the paper and make final adjustments in your development tool while having a conversation.

Some tips:

• Gloss over details in your drawings. You need just enough detail to communicate your design.
• Aim for quantity not quality.
• When doing this for the first time, don't tell your team they only have five minutes until after they start.
• Do steal ideas from each other.
• As always, include your client in these sessions.

Results

Four of us met in a conference room to try out this new approach. For a user scenario that included about 10 stories, we executed three rounds. As a team, we were very pleased with the results and how quickly the final design emerged. Despite starting with very different ideas, we discovered that by the third round our drawings were nearly identical and represented the best work of the team. Using this approach helped generate ideas none of us would have thought of individually and resulted in team ownership of the design. We also found that we identified a few new 'excitement' user stories to add to and enhance our existing backlog. Additionally, as we walked through each other's drawings we discovered one or two basic stories that we had missed while generating our initial backlog. Time will tell if the resulting UX design will be successful, but as a whole the team is confident in both the approach and the result.

In summary, this approach was fast, promoted team ownership, and produced a great result. You can learn more about the Design Studio approach here: http://unify.eightshapes.com/page-pattern/sketching-design-studio-page-patterns/

I thought the success of this team approach was appropriate to write about on a day where this quote was found in @ThisIsSethsBlog - "I'm not going to believe that only a few people are permitted to be gatekeepers or creators or generous leaders". Indeed.

Update April 1, 2011: I introduced this approach to a larger group of my fellow employees this week. Someone asked "why we should continue with round 2, 3 etc - why not just have the group consolidate the good ideas and produce one design together after round 1?" 

My answer: If you consolidate your ideas after round one then you are risking two things: 1) That the 'loud' voices will be the one driving the ideas and design. The practice of having everyone re-drawing the design allows each person's ideas to be incorporated. 2) As you repeat the process of re-drawing your design, the ideas from your team members will seep into your ideas and birth new ones. If you consolidate your design too early, you risk losing those new ideas that can only form in the act of putting your ideas down with paper and pencil.

Agile Winnipeg Inaugural Event - "Shorten the Distance"

It was pretty exciting for myself and the other organizers to see a packed room of over 60 people attend the first Winnipeg Agile User Group event on Thursday, March 10, 2011. After a quick meal from Homers and some furniture re-organization, we kicked off the event with a word from several of our sponsors. Wadood Ibrahim spoke on behalf of Protegra and recalled giving a presentation to the local PMI group 10 years ago about agile techniques that was not well received and was delighted by the turnaround of opinions and interest 10 years later.

For the main presentation, Doug Kok and I split the attendees into groups of about 15 people and led them through the ball point game. The ball point game is a simple and fun exercise that allows teams to think about process * people through team decision making and the power of reducing hand-offs. Here are a few images from the event:

Team 1 Discussing their strategy



The scores of the game. Notice the significant improvements from most teams. Team 3 forgot to count during the last iteration, but based upon the process they were using, I think they would have surpassed their estimate of 160



And, thanks to Doug - here is a brief video summary of the teams playing the game: 


So how does the ball point game relate to agile? In both the ball point game and in software development, improvements in speed can be gained in similar ways:

• Focus on reducing hand-offs by having face-to-face conversations, dedicated teams, shortening the distance between a requirement and its implementation, a question and its answer, etc.
• Stop frequently to determine how to go faster.
• Measure your experiments through velocity and frequent feedback.
• Value and encourage cross-functional, de-centralized, self-organizing teams.

Homework: To take this further, read the 12 principles in the Agile Manifesto and think about how each of the 12 could be re-stated as a way to reduce handoffs, or as shortening the distance between [A] and [B]. Also, to see how these ideas can work in the 'wild', read this case study on facebook.

To close the event, we held a short open Q&A session. Some of the questions we discussed were:
 1. Can you do agile without TDD (Test Driven Development)
 2. When/how do you do requirements?
 3. How do you control scope creep when you aren't defining the requirements up front?
Lively discussion continued over drinks at Triple Bs on Scurfield.

Based on the survey responses, the top 3 categories for future event topics were Agile Testing, Agile Adoption, and Agile Estimating.

Finally, on behalf of the organizers I would like to thank you for participating and thank the sponsors for allowing this event to occur. To register for future event notification, please click here.

What I learned about agile teams from 8/9 year old girls basketball

I am a very fortunate daddy. I am one of the coaches for my eldest daughter's basketball team. The community league she plays in has a rule designed to promote team work that at first glance may seem counter intuitive - "No double teaming". This means that in most circumstances when playing defense each girl must cover her own 'check' and can not help out her teammate. To explain this a little more, I'll give you two examples.

Example 1 - double teaming:

Mary is new to basketball and is tentatively dribbling the ball over half court. Ann is playing defense on Mary and is doing a pretty good job of limiting where Mary can go and who she can pass to. Laura is a very strong player on Ann's team and notices that Mary is struggling and that she has an opportunity to make a play. Laura leaves her own check, runs over to Mary (who is now double teamed), steals the ball and races to her own basket where she scores an easy two points. Her team cheers loudly.

Example 2 - helping:

Amber is an experienced basketball player and is dribbling the ball over half court. Kari is playing defense on Amber but is having trouble limiting where Amber can go and who she can pass to. Deanna is a very strong player on Kari's team, but because she is not allowed to double team, she does not immediately race over to help Kari. Amber makes a quick move that allows her to get past Kari and race towards the basket. At this point, Kari knows she is in trouble and yells 'help'. Deanna races over and gets in front of Amber to slow her down just enough so that Kari can catch up. Once Kari has caught up, Deanna races back to her own check and Kari resumes playing defense on Amber. No baskets are scored and mild applause is heard.

The nature of community led basketball leagues is that there is a combination of inexperienced but willing coaches and inexperienced but willing referees. This means that most times example 1 occurs without the ref or the coach interfering. While our team has been mostly executing as example 2, many of the teams we play against have been executing mostly as example 1.

Over the course of the season, the result has been interesting. Teams that were beating us at the beginning of the season by taking full advantage of the skills of their best player through double teaming are now struggling to even have a chance to score against our girls. The girls on those teams are trying just as hard, but the double teaming strategy that worked so well early in the season is no longer effective.

We have a team of 10 girls who have each improved. Some of the girls are more skilled than others, but each girl has improved noticably from the beginning of the season. The net effect is that our team has also improved noticably from the beginning of the season. Maybe more importantly, this team supports each other, learns from each other, and trusts each other.

Note: It would be easy to credit our brilliant coaching strategy, but that would clearly discount the effort, teamwork, and skill of the girls on our team. They are a wonderful group.

The parallels for agile teams are pretty clear to me. If you expect your team to perform at a high level, you need to let them improve at every role and reinforce team ownership of the project.

• If you are the PM, don't take sole responsibility of the budget, tasks, project goals etc. Make these visible to your team and help your team own them and make decisions about tasks and priorities together.
• If you are the DBA, don't get upset when the database design is insufficient, teach the team how to improve their design the first time. Work with them rather than 'fixing' their work later.
• If you are a tester, don't assume full responsibility for testing, teach your team how to be better testers by testing every day and pair testing with the developers.
• If you are the UI expert, involve your team when designing the UI. Lead the exercise, but don't steal the design for yourself.

Of course, the converse of all of these is also true:

• If you are a developer, take responsibility for the budget and priorities
• If you are a tester, learn how to code a little
• etc.

There are other lessons to be learned from 8/9 year old girls basketball, like how to ask for help when you need it, but those are for another day.

Occasionally I meet former co-workers who inevitably ask me what I'm doing. When I announce my agile and lean passions and talk even briefly about the differences between traditional teams and agile teams, I often am greeted with a response something like "But someone still has to manage the team and the budget right?" My answer is usually "Yes, but it doesn't need to be you anymore. It should be the whole team."

As the African proverb says, "If you want to go fast, go alone. If you want to go far, go together."

Perfecting your process

“Eliminating delays between what you do gives you a better return than getting better at what you do.” - Alan Shalloway (Dec 2, 2010, twitter).

I was recently introduced to the ball point game as a way to introduce agile concepts. A colleague of mine had decided to try it out for a larger group so I volunteered one of our teams in order to ‘test drive’ the game and the facilitation of that game.

The game itself is pretty straightforward. If you want to read about it, check out Declan’s link above or one of the many other sites describing the game. One of the objectives of the game is to show how teams can dramatically improve their process just by stopping, reflecting, and re-planning.

This particular team improved from a velocity of 28 to 57 in four iterations (see the image). However, if you read about this game from other sources, this kind of improvement is ok, but not great. The team focused their iteration planning efforts on perfecting their style rather than changing their process. They did discuss some alternative processes but ultimately rejected them and decided together that their best course of action was to perfect their current method.

To make matters worse, as facilitators we were terrible project managers as we told them stories of great improvements by other teams (“I bet you can get to 150, I’ve seen other teams do it”) but all this did was make them frustrated as they continued to try and perfect their process with only small gains. Plus, even though they doubled their efficiency in a short period of time, they were frustrated that they couldn’t go faster and started to slow down at the end of iteration 4. They suggested that if an iteration 5 would have been held, they would only have gone slower as the realization sunk in that they would not be able to achieve 150.

The exercise up until this point did not achieve what we had hoped for. We had hoped that they would find huge jumps in productivity each iteration and that they would get more and more excited each iteration. Instead, they only achieved modest gains and got more frustrated each iteration. So, what did we learn from this?

1. As the quote above says, it confirmed that focusing on improving and perfecting your current process is only going to give you modest gains. Practice doesn’t make perfect if your process is flawed. Continually practicing a bad process isn’t going to result in the benefits you are looking for and will likely slow your teams down over time as apathy builds. We need to give teams the lean tools and techniques to help them find their delays. One of the ‘tricks’ to this game is to reduce or eliminate your delays instead of perfecting your throws.

2. We need to give teams enough time to not only re-plan the next iteration, but to ask them to reflect upon and challenge both their process and their assumed constraints.

3. Teams who are pushed to achieve incredible productivity gains by well meaning leaders under the guise of empowerment or encouragement may see short term gains, but in the long term those teams will likely be negatively affected - especially if the teams haven't been given the tools and techniques to achieve those gains.

The team we tried this with did not at first come away with tools that they could use to improve their current project. In fact, we may have scarred them forever ;) We are trying this game again in a few weeks with a different group and we’ve made some changes with the hope of enabling the teams to see the ‘ahah’ moment before the end of the game. I’ll keep you posted.

Why is collective team ownership and commitment better than individual ownership and commitment?

Recently I've been pondering collective vs. individual ownership and commitment, the theories behind it, and how to respond to someone who many not have considered why collective ownership and commitment is important. If you are involved on a team that is assigning responsibility to individuals, you could respond in several ways. My own impulse may be to respond either with frustration or to smile, nod and wink to my more agile-aligned team members. However, I have never found these types of responses to be very productive ;). You could also respond by informing the team that the agile community is full of luminaries who tell us that individual responsibility is not compatible with good results over the long term. However, as you can imagine, it also won't be an effective strategy just to tell your team that Johanna, Brian, Bob, Esther, James, Jeff, Mary, (etc) and you don't think this is an effective way to manage the work. Instead, I suggest that you a attempt a face to face discussion on the pros and cons of assigning the work to the team vs. the individual. Here are a few things you might use in your discussion.

Team ownership reduces the risk of having or creating one 'smart person in the room' (i.e. bottleneck) who does all the work. Even though Jim may be the best person to complete the job, if Tim and Jane work on it together with Jim it will take a little longer initially to complete the task, but those gains will be realized over the long term as the whole team becomes better at accomplishing each task and filling each role. While a cross functional team isn't always easily or immediately created, eventually that team can function effectively to complete any task even if one or more team members are missing.

Collective ownership should result in less items that are in progress. Work in progress tasks have zero realized value to the organization's goals. If we commit to and own items as a team, we should work hard to get them done one at a time so that we can realize the value of those items sooner. Rather than 5 people completing 5 tasks individually that are finished together at the end of the month, task 1 is finished and creating value at the end of week 1, task 2 at the end of week 2, etc.

Quality has a better chance of being built in from the beginning when a team owns and takes responsibility of a task together. As the team works together on a backlog item, we will collectively discover our 'quality blind spots' earlier in the process and adjust accordingly. When I work on an item myself and then present it to the team for review after I'm finished, there will be more re-work required to incorporate the ideas of my team members in order to mark the item as done. It is critical to get feedback early and often in order to 'fail fast' and improve quality. Teamwork is an effective way to accomplish this.

Finally, collective team ownership promotes... teamwork. Individual accountability and responsibility tend to generate selfish behaviour (I'm working on my task that I'll be measured on so I can't help you with yours). Team accountability and responsibility builds a stronger team because if any one task is sub par it reflects on the whole team and not on an individual.

Of course, this doesn't work very well if we don't sit together - which is why we do.

Planning Poker and Buckets of Hockey Pucks

The teams I've been working with over the past while have been using planning poker for project estimating. Despite initial and fleeting skepticism by a few when we bring out the cards, as a whole our teams and our sponsors are finding value in this approach. I was reminded today that we should look at poker points as buckets of sand. That is, when deciding between a 5 and an 8, if something is a 6, you can probably still put it into a size 5 bucket if you think of the points as sand that can be heaped at the top of the bucket. Also, a 7 would overflow a size 5 bucket but would fit easily into a size 8.

In light of Canada's 7-3 victory over Russia in Olympic quarter finals, I've decided to change the metaphor to buckets of hockey pucks instead of sand. Go Canada!

P.S. I'll be presenting on Planning Poker in Regina in June at http://www.prairiedevcon.com/