I enjoy the Agile Ball Flow Game. It’s a challenge that emphasizes a lot of what agile practitioners find value. The theme of the game is that you’re working in a toy factory and you create toys by passing them around to the other workers. Each worker needs to touch the toy at least once, no two workers can touch the same toy at the same time, and you can’t pass the toy to the person next to you. As orders come in, you try to complete the orders as quickly as possible. If you mess up one of the toys (drop it), you have to start over creating the toy.

In the game, you want to keep track of when you start making each toy and when each one completes. This lets you track your lead time, cycle time, WIP, etc. From this information, the group can see what works well and what doesn’t. They can determine how to adjust their process to improve their toy-making abilities.

At the Hudson Software Craftsmanship meeting earlier this week, we performed the agile ball flow game. No one there had done it before, so it was a great opportunity to see how they would organize themselves and complete the solution. In total, we had 14 people at the start of the game.

Round 1

I started the group off with 20 multicolored balls. The hollow plastic variety commonly found in children’s ball pits. They’re easy to toss short distances, but can be tricky for a long distance toss.

They first created a circle to facilitate passing. One thing they did very right was passing 1 ball around as a demonstration so that the whole team could practice and get an idea of what they were going to be doing. Much better than just assuming that everything will work as expected!

They completed the full order of 20 in just over a minute and thirty seconds. A few of the balls dropped, but were picked up and reintegrated into the process. Their effective process worked so well, because most of the team had enough slack to not feel overwhelmed.

Round 2

In the second round, the team estimated that they would be able to complete things faster. They estimated the time to complete to be around 45 to 60 seconds.

As part of their retrospective, they realized that their pull model they were using worked effectively, but if they shifted forward and backward a little bit, they could pass more easily. This was their slight adjustment to the process.

It worked! They managed to keep more balls from falling in the second round and really improved their time! They noticed that their issue was in contentious passes around the circle, and they adjusted to account for it. Well done! They were a hair under 40 seconds, which is the fastest second round time I’ve ever seen.

Round 3

Kids these days aren’t just interested in those old-style toys, which means that the challenge needs to change a bit. They’re still fun, but the new thing is dart guns, so now the team needed to also pass around foam darts. With such a well oiled machine, could these darts present a challenge?

The darts are tricky, because one end is rubber and weighs a bit more than the other end. These were obviously more challenging to pass, and the group spent some time discussing how they would work.

The team decided to start with the darts to get the more difficult items out of the way first. At first, this seemed to work, but darts started falling. After starting most of the darts a second time, the group ended up with a time just over a minute and twenty seconds. Not bad, but quite a fall from round 2.

From the retrospective discussion, the group established that they needed to drop the darts into people’s hands. Tossing just wasn’t working well. They also decided that they should probably send multiple darts at a time since they were going to be dropping them, it should be safe to do.

Round 4

Armed with a new plan, the group decided to start the darts 5 at a time, which would mean 2 sets of darts traveling around the group.

Not surprisingly, only 3 darts of each set made the round trip. Still probably an improvement, but it might have been better to have done 2, 3, or 4 darts at a time instead. Perhaps something to try in the future.

This round was full of dropped items and ended with 1 dart making the rounds all alone. In the end WIP was just 1 for the whole group. The time wasn’t bad, but it was obvious that the group could do better. So far they hadn’t made any huge gaffs either though.

Round 5

This round was about being more careful and getting the passing in place as best they can. Perfect answer, team. They knew not to make big changes. What they were doing was working, and they were seeing improvement. A big change here would just upset things.

The group finished on a high note, being one of the more successful groups at ball flow that I’ve seen. They completed the challenge like champs. Not once did they try something crazy like shooting WIP through the roof (I’ve seen it!)

Agile tells us that we need to limit WIP and bring cycle times down. Those are the focuses of the agile ball flow game. It lets the group self organize through planning, spiking, testing, and doing retrospectives. If you want to teach a team about agile, the ball flow game is a great way to do it!

I primarily use Karl Scotland’s method of running the agile ball flow game. Make sure that you also use this spreadsheet template when running the game. It makes tracking times much easier.

One of the agile communities mocking terms of the old-fashioned Waterfall development technique is, “Waterfail”. It is called this, because the community credits this technique with being part of why a lot of projects fail.

The main difference between this technique and most agile techniques, is that waterfall does one big flow of everything. It does not loop through the process as most agile techniques do. It attempts to have everything planned out so that you’re just going through the motions toward success.

I’ve been posting each of the topics from the NimblePros software craftsmanship calendar as we get to the month. With each of these, I am mentioning that you should work on trying to follow the good practice or avoid the anti-pattern. Since this year’s calendar is on anti-patterns, it included Waterfail as something to avoid.

So for the month of August, I am going to recommend trying to move away from Waterfall. I’m not saying that you should suddenly move from a Waterfall project to some form of an Agile project. At least start looking into the possibility. Read a book on agile, go to an agile or software craftsmanship user group, access online resources for learning agile techniques, or attend a conference with an agile track.

I really liked how well this image turned out, and if you didn’t notice, we wrote “Waterfall”, but we cut part of the first “L” to make it appear to say “Waterfail”. Just one of our subtle little tricks in the calendar.

Go here for a more thorough analysis of Waterfall.

Programmers are talented, smart, skilled professionals. We put in lots of our own effort to educate ourselves and stay up on current technologies. We work hard and we feel great satisfaction in our achievements. We donate our time to charities when the opportunity arises. We give back to our local communities. All things considered, there are a lot of really great programmers in the world.

I lead a team of software developers. Does that mean I am the “best” programmer on the team? Certainly not. It just means that I lead the team. As the leader of the team, it is my job to: inspire, encourage, trail blaze, and motivate my team to be the best they can be. So who is the best programmer on my team? I don’t know, and I don’t care. There shouldn’t really be a “best” programmer on the team. Everyone on the team is great and working hard.

A team that really meshes and works well together doesn’t let egos get in the way. It doesn’t matter if you’re a rock star developer. When you’re on the team, you’re part of the team. You might be the JavaScript expert, the master of SQL queries, or the guy who can refactor anything. When you’re part of the team, you should try to use your strength, but don’t let that interfere with the team’s flow.

Sometimes it makes sense for a more experience developer to work with a less experienced developer. A common first instinct is that the senior person is mentoring the junior person, but it’s actually going both ways.

Each of the two developers is bringing a lot to the table. Their different experiences and views allow them to each approach the problems differently, ask different questions, and apply different, existing knowledge.

If either person’s ego gets in the way, it would prevent the 2-way knowledge transfer in addition to creating friction between them.

One Developer and one Junior Developer can pair on a task and share knowledge. Does one act like the other one is just along for the ride? No.

Your pair partner, is watching your back, guiding the team, and keeping the pair honest. Which one does that job? Both. If you had one person drive the whole time, you’re not going to see the benefits of pair programming.

If you let your ego get in the way, you might not let the junior developer write any of the code. They may not know every library, every design pattern, or even the intricacies of the language they’re using, but those guys can write some great code.

I don’t know how the Junior Developers are on your team, but ours write great code and show a high level of professionalism in their work.

And sometimes you get a Junior Developer pairing with the Developer Intern. How the pairs split up doesn’t really matter. Who is working with whom doesn’t really matter. Each and every member of the team is bringing something to the table, and it is this interaction that is making the team as effective as it is. These two are as productive a team as any other pairing that we’ve got.

Someone is probably reading this and thinking I am crazy for letting a Junior Developer and a Developer Intern pair together. They’re good though, and they really get great stuff done.

We can accomplish a lot of stuff when our team works individually, however, we can accomplish a lot more as a group. You might be the “best developer” on your team, but if you keep thinking and acting that way, you’ll be missing out on a lot. I learn a lot when I pair with any member of my team. It doesn’t matter how much experience the person has. Everyone knows something I don’t, and no one approaches the problems exactly the same way I would.

There is no “Ego” in “Agile Team”, so don’t bring yours to an agile team and expect good results.

I recently read The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series), and it is one of the best books on software development that I’ve ever read. The book is a quick read from Uncle Bob Martin and is comparable in size to his similarly named, Clean Code: A Handbook of Agile Software Craftsmanship.

The book goes through many, many examples from the author’s development experiences. It has sample discussions between parties to explain points and really goes over professionalism in software development.

The Title

The impression I have about why the book is called “The Clean Coder” is mostly a play on professional developers wanting to have clean code. This doesn’t just mean the code, the code is included of course, but it also means that the whole coding experience and the whole project should be clean.

There are a lot of mistakes that developers can make, and the book is covering them and discussing how to keep things clean.

The Material

Without jumping into too much of the meat of the book, I will say that there are many things in the book that I’ve done before and don’t do anymore. There were some things mentioned that I’ve done recently, and I am going to make sure I never do again. There are some things in there that I’ve thankfully never done, and I hope I don’t ever do them.

The book focuses on a lot of bad situations, why these situations are bad, and how we should really be handling things.

Consider this book to be a guidebook of suggestions for how to act as a professional. For example, in the book’s discussion of estimation, instead of focusing on how to be more accurate with estimation, it covers how you should be estimating. This means that it tells you that you should be very clear about things being estimates, not to imply a commitment, and not to make commitments if you cannot meet them.

Controversial Points

The Clean Coder makes some recommendations that I am sure that plenty of people will disagree with, and the way some points are worded cause me to sometimes disagree as well, but I don’t think it really takes away from the value of the book.

One example of this type of suggestion is that you work 40 hours a week and then another 20 each week on improving your career, leaving 56 hours for sleeping and 52 hours for everything else. It’s presented as doing this makes you a professional and not doing it is not professional. What I disagree with is the definite amount of time. I think it’s important for people to work on their careers, but 20 hours is arbitrary here. Someone may get the same value out of 10 hours that requires me 30 hours. There also is no definitive line between professionalism and unprofessionalism. There are some gray areas, and I believe this would be one of them.

Some things in the book were kept clear that it’s how he works, and I took these as suggestions to learn how I work and make sure that I am evaluating a possible issue.

In this case, I am referring to a point on music. Some people listen to music lightly while programming. This is even true when pair programming. I sometimes like having a very light bit of background buzz from music while pairing. In this case, I keep it so quiet that we can still communicate easily. The book seems to be against music, since it distracts and changes the author’s thinking. For me, I think I don’t have this issue because my pairing partner prevents a change in thinking. I also try to listen to music with foreign lyrics or no lyrics at all. It also helps to not distract from the task at hand. The value here for me is that I should be evaluating and thinking about how I am doing things to make sure that something as seemingly inconsequential as music is not detracting from my work.

Meetings

One great suggestion made by Uncle Bob is that it’s OK to decline a meeting invite. I think that’s very important to understand. Unless you’re really needed in the meeting, you should try not to attend. Meetings take up time, and if it’s less important than your other work, you shouldn’t be attending.

I had a meeting I scheduled yesterday. I invited 8 people to that meeting. I made sure it was clear that if you had something to bring up, you should attend the meeting, otherwise your attendance was not required. We had 4 people in the meeting, and I think 1 of the attendees need not have been there anyway.

Trying

You should read the section on trying. It’s important not to try, and this book makes it very clear why. If you’re going to try, you’re making a commitment to try.

Mentoring

The first paragraph on the chapter on mentoring illustrates one of the biggest shortfalls of the software development industry. I owe a lot of my successes as a developer to the mentoring that I’ve received through books, blogs, and any other recorded sources of information I can get my hands on. I was also lucky enough to have a mentor and a role model to learn from as I became a better developer.

Summary

If you go in to this book expecting it to be a recipe for success, you will be mistaken. This book is fantastic, but it’s important to think and consider why it’s valuable. It is one developer’s experience as a developer.

From his own stories, he is a developer who has hit some pretty rough patches and made some terrible mistakes. That’s a good thing! It means that he has learned a lot!

While reading the book, I never felt like it was forcing his way of doing things onto me. It is presented in a great way to inspire changes in the developers who read the book. You don’t have to do the same things that he is doing, but try to consider what the right answer should be.

The examples are simplified for the book, and business are more complex than what is in the examples. The reader will need to adjust and make decisions, but that’s what you should be doing anyway. Think about being professional and doing what you should be doing.

This book has been on my intended reading list for a while, and now I am going to recommend it to other people.

Well done, Uncle Bob. Thank you for sharing your experience with everyone.

I believe there are two main types of “teams”: those working together, focusing on doing their best as a team and those working individually, focusing on doing their best on their own. (Yes, some teams are in between.)

I think you can guess based on my wording of those two options, that I prefer working as a team toward a combined goal. By working together, we can accomplish much more. We must be careful along the way, however, to make sure that we don’t do anything that can hurt the teams abilities to work as a team.

Building a good, cohesive team is my greatest achievement in my software development career. Being a part of this team as it achieves great things is what I have received in return. – Brendan Enrick (March, 19, 2012)

I am always trying to make sure that the team is doing well. I try to keep them focused and working together. Most of all, I try to make sure that the things I do don’t hurt the team. It’s important to recognize that decisions and choices we make affect the team a great deal.

Building strong teams requires a lot of work. This post focuses on considerations that I believe are important to creating strong teams. These considerations include: communication, co-location, combined interest, respect, and commitment consensus. I focus on these when trying to create good, cohesive teams.

Communication

Creating great software depends heavily on communication. This is important for the whole team. It’s important that all members of the team be communicating with all other members of the team. If communication breaks down, the team is soon to follow.

It’s important for the whole team to be talking, writing, documenting, and sharing their ideas. Make sure that your team feels safe working together and communicating with each other.

Communication is so obvious as an important aspect of a good team, that I am not going to spend a great deal of time discussing it.

Co-location

There is no easier way of getting a team to work together than to have them located together. Keeping the team close together keeps communication high. Not only does this mean that asked questions will be answered quickly, it also means that questions will be asked. If the team were not together, someone might not have asked the question. This keeps the communication barrier low and the feedback loop short.

I said this was an easy thing to achieve, and it can be. Sometimes there are difficulties with logistics of your space, people not wanting to move, etc. These can happen and can also be worked through. If you don’t have a team room, you can still set up a “command center” in an unused conference room.

I’ve seen both introverts and extroverts do well in co-located teams. When the conversation is on-topic it allows everyone to tune in to what the team is doing. The team will start answering questions immediately, knowing what everyone else is working on, chiming in with assistance on an area of expertise.

Combined Interests and Goals

It’s extremely important that a team have a shared goal. If you fragment the goals of your “team”, you will be fragmenting the “team”. You run the risk that the team will have no incentive to work together. Yes, you might say that since everyone gets along, they’ll work together still, but you’re driving in a wedge that will pull them apart.

I don’t want my team to have individual goals, this will cause them to work on their own and make it harder for them to work together. Anyone spending their time helping someone else would be in danger of not finishing their own work, but I want them working together to achieve more.

Nothing is as detrimental to a team than making them behave less like a team.

By combining the goals and interests of the team, you force them to work together. They get the idea that they’re being graded together and being rewarded together. This will keep everyone on the team at  their most productive, because they will all have each other to lean on.

Respect

This word gets four uses here. It is important that members of a team treat each other with respect, it is important that members of a team respect each other, it is important that each member respects oneself, and it is important that everyone respect the code being written.

If one member of the team doesn’t respect another of the team members, the team will not be cohesive. If one member of the team doesn’t show respect to one or more members of the team, the team will not be cohesive.

If one member of the team doesn’t respect oneself, the team will not be cohesive. If one member of the team doesn’t respect the code being written, the team will not be cohesive.

When the team has respect for each other, they will strive to not hinder the rest of the team. This means that they will try not to break the code base. They will try to make sure that they build good, simple designs that everyone can appreciate. And communication will also flourish.

When the team has respect for themselves and the code they’re writing, they will strive to write clean, simple, well-tested code. The team will care about the work they’re doing and will avoid creating a big messy codebase.

Commitment Consensus

Making any commitment as a team must be done with a consensus among the group. One of the worst things that can be done to a team is to set their commitments for them. You can’t tell someone else what they are required to commit to.

Commitments have to be made willingly or the commitment might as well not be made at all.

This mistake is commonly made by people assigning work for the team to work on without getting their feedback on it. If you assume that a team can get X amount of work done without asking them, you’re asking for trouble. First, you’re making their decisions for them. This is going to make you into the opposition of the team. Second, you’re not soliciting their opinions or feedback.

Often this means that someone who is not going to be doing the work has estimated the time the work will take to complete and has assigned this work to individual team members. This will break the combined interest, encourage the team to break from their co-location, and cause the team to feel the person making those decisions isn’t taking them into consideration.

The right way is to work with the team. If you do need a commitment on something, you should work with the team to create that commitment. This usually means sitting down and working with them on it. Get them to decide what they can accomplish in an amount of time. Work with them to decide what will be worked on. This means that the person deciding the direction of the project should be directly talking with the development team doing the work.

Getting people together, working together, collaborating, is what makes teams effective. Don’t try to force them into doing something they don’t want to do. It will backfire on you. Plus, they’re likely not going to uphold that commitment. It wasn’t their commitment anyway. Not really.

The Team

If you manage to get the team working together effectively, keep it up. Try new things, but don’t let it destroy the team. If it looks like it’s hampering the team’s togetherness, quit doing it. Find another way of doing whatever you’re doing.

Don’t force the team into processes they don’t like. Let them create a process that works for them. Give them the tools and enable the team to make the right choices. Empower your team! Make sure that you never become the opposition of the team. Try to be part of the team. Align your interests with theirs.

The following post is a list of useful practicing resources. These include: coding katas, programming exercises, and educational software development games.

If you’re not sure why you should be doing coding katas and exercises, I have this old post explaining the benefits of coding katas.

Coding Katas

• Bowling Scoring Kata
• FizzBuzz Kata
• Gilded Rose Refactoring Kata
• Greed Kata
• Potter Kata
• Prime Factors Kata
• Project Euler Problems
• String Calculator Kata
• Supermarket Pricing Kata (Sample Output)
• Tennis Scoring Kata

Games

• Agile Ball Flow Exercise (imagine the 1990s under construction gif here)
• Agile Pizza Shop (imagine the 1990s construction gif here)
• Marshmallow Challenge (imagine the 1990s construction gif here)

Recap Posts About Katas, Exercises, and Games

• Ball Flow Recap: CodeMash Coding Dojo
• Software Engineering 101 Cleveland Slides and Demos

If you’ve ever had a team responding to the needs of multiple stakeholders I am sure you’ve seen some interesting trends. Some stakeholders will sit quietly and have their requests ignored while others will always push their needs to the front. This of course happens in a lot of different fields. There are always the pushy people who want their stuff done first, because it’s “top priority”. Maybe it is, but that’s not for the team to decide.

So how can you prevent problems from arising from this type of behavior?

I recommend that you spread as much information about things as possible. In the past I’ve found that when dealing with decision makers it is best to make them aware of the other things you’re working on. If your team has an informative workspace that makes available all of the tasks you’re working on they’ll be able to see what is currently being worked on.

Keep your backlog of tasks in priority order and make the whole thing visible. Make sure also that adding something to the front will require physically moving another task back. It’s much harder to ignore the displacement of someone else’s request when that request must be physically moved.

Another great way of handling this is to make sure all of the stakeholders are present when ordering the list of tasks. This will make it quite clear if one person’s requests are all being put at the front of the line, and can help allow for some compromises to occur instead of an argument.

Disagreements over whose need is more important are not the place for the development team to be involved.I’m not saying that a fist fight will break out, but you want to avoid upsetting anyone. Your best situation is when you don’t have to make a decision about whose task to work on. I find that people are more considerate of other people’s needs when they’re made visible, so make sure that stakeholders see the displacement of another’s work.

Don’t be overprotective of your source code. Allow others to make modifications, improvements, refactorings, and even defects (as long as those get fixed immediately). I am talking about two different Extreme Programming practices here: collective code ownership and pair programming. A non-developer friend of mine has been reading about agile software development and asked me last week about pair programming, "do you guys do this 'pair programming' thing?"

I think even among developers the pair programming concept is one of the strangest aspects of extreme programming.

Yes, a lot of agile development teams use pair programming. We even equip our facilities to make pairing easier. Our computers have 2 large monitors, 2 keyboards, and 2 mice. Some teams pass the keyboard and mouse back and forth, and that works just as well.

What is Collective Code Ownership?

This is a great term that basically says that every member of a team should be able to work on any part of the system. If you’re usually working on the user experience you can still spend some time working with your application’s service layer, and if you’re the database guy you can work on some business logic.

Wouldn’t someone be able to do that job better? Yes, there probably is someone who knows each part of the application better than anyone else. You can work with that person if you want, and the two of you will be able to create some great code. What if that person who is better at that task is on vacation? Wouldn’t it be great if someone else knew the code.

Keeping the team familiar with the project means that the team can focus on certain parts of the system at a time and achieve great results. You don’t have to split your team based on layers or modules of your application. Let them intermingle. Fresh ideas and eyes can greatly improve things. They might come along and fix a defect or two for you later; saving you a great deal of work.

Why Pair Program?

The mind is the important part of programming, so why not have two? After all, programming is certainly not just typing. If you believed that how could you ever support pair programming?

If you pair program for every line of code in your application then you know that you’ve had at least two sets of eyes look at every line of code. This is a good deal of added security.

When you create some new piece of code that the whole team will need to work with, pair programming can be the solution to disseminating this information. You and the guy you created it with can split up and pair with another person each, and while working on the code you will each be showing your new partner how the new code should be used. This allows new information to spread quickly through the team.

Even the simplest things as learning keyboard shortcuts are improved by pair programming. When I use a cool keyboard shortcut, I can tell my partner what it is without breaking my train of thought. We can keep on typing, and when he has the keyboard in a minute or two, he can try it.

Just like athletes, a programmer needs someone else there to help him keep the pace. You partner can help you avoid distractions, and most importantly he can keep you from taking shortcuts. When we write code we might say, “I can fix this later”. The partner will make a note of it and be sure you get it fixed later. If it can’t wait and you’re in the middle of something you can always pass it to another pair. Your partner can do that while you keep on coding. Remember that the other pair can work on any code because of the collective code ownership.

I am sure I missed plenty of reasons to pair program, but this list feels mostly adequate to get the point across.

Please let me know why you do or do not pair program. Is it work related? Are you an unbeliever?

In what I would call the worst-case scenario,a customer’s involvement in a project could consist of setting up initial requirements at the start of a project and then viewing the results at the end of the project. This is of course not ideal for either the customer or the team developing the software.

In the next best scenario the customer could show up at the beginning and end of each release. This is still not enough. Why? At that point there is no slack remaining. What if the customer doesn’t like how something was done? What if there was a misunderstanding? What if the customer has something new that your design makes as a new requirement?

If the customer doesn’t like your design and you need to go and redo things, your time and the customer’s money has been wasted. I know it can be challenging with some customers, but you want to show them what you’re working on before you’re done. The customer can make changes based on what you show them.

When you mock up a design for something, show your customer. When you first set up the screen, show it to them before you’re done.

The customer will like that you’re keeping them involved. They can make changes now rather than at the last minute, which is good for you. You get the benefit of having questions answered. You can remove guesswork. If you got it wrong, don’t worry, the important thing is that it didn’t release that way.

Disconnects between the customer and the development team can happen easily. The customer doesn’t know why things take so long or even what you’re working on if you don’t tell them. You may feel like the customer is sabotaging your success if you wait until the end to show them what you’ve created. Get your constructive feedback earlier and you and the customer will be happier about the results.

This applies to agile teams as well. If you’re an agile team you may think that your weekly iteration gives your customer enough involvement since you can show them at the end of an iteration. It isn’t enough. You need your customer’s feedback throughout the iteration. In order for agile development to work you need to make sure that you are done  with your work at the end of every iteration. You can’t be done until your customer signs off on it, so make sure you’re getting them to sign off on things during the iteration. If you don’t you’ll never finish an iteration on time.

One challenging part of software development is estimating the amount of time that tasks will take. Why is this a challenge? There are plenty of reasons: sometimes you’re dealing with legacy code, sometimes there are a great deal of unknowns, and sometimes you aren’t doing the whole story and can’t estimate the other work. There are plenty of other reasons why estimating stories is difficult, so how do you resolve the difficulties and get things estimated.

 

Improving Estimates

I find it is best to bring the whole group together to make estimates. With a group, you’re less likely to forget about different aspects of the project. You’ll have everyone there who will be doing the tasks. Someone there may know more about the legacy system or a certain part of it than you do.The group should help prevent you from making any unrealistic estimates.

Another great way of improving your story estimates is to do the estimating shortly before you’re going to be doing the work. The best estimates you can make can only be done immediately before doing the task. Any earlier and you don’t know exactly how the system will be architected. Estimate any earlier and the system may have become easier or harder to change before you start the task.

To help build group consensus on the estimates you want to limit the number of options available. With too many numbers it will be very hard to get everyone to agree. You also want to have less options as the numbers get larger. The reason being that larger estimates are less accurate anyway, so you really just want a magnitude for the estimate. Is this a day-long task? More?

Find some nice system to limit the numbers. A great way that I’ve seen used in the past is Fibonacci numbers only.

1, 2, 3, 5, 8, 13, 21…

That set allows for some accuracy at the bottom and some good general choices up higher. 8 is great because it is a full-day.

My favorite set of numbers for estimating is using the powers of 2.

1, 2, 4, 8, 16, 32…

I’ll explain later why I like this set of numbers.

Another easy set to use is Prime Numbers (with 1 included).

1, 2, 3, 5, 7, 11, 13

Whatever set you choose make sure that the group knows which ones you’re using and stick with it.

Implementing Estimates

Once you select your strategy for estimating you’ll need to implement it. Estimating should be done close to when the task will be done, so I recommend estimating on each Monday all of the stories for the week.

Bring everyone together and make sure they understand how the estimating will be done. You want to start by reading one of the stories. Let the team ask any questions about the story. Once everyone understands the task you get to estimate.

Make sure that everyone selects their estimate secretly this is important so that no one’s estimate is influenced by others’ estimates. I’ve seen a few interesting ways of doing this.

The cheapest approach is to have each person hold up a number of fingers equal to his estimate, and then all estimators reveal their estimates at the same time. This is kind of like a game of rock-paper-scissors. We can call this approach Rock-Paper-Estimate.

Another easy approach is to have everyone write down the number and reveal at the same time. You could use paper for this or little whiteboards.

A very cool trick that was brought to my attention recently came from someone handing me a deck of cards from the Visual Studio 2010 launch event in Las Vegas. Planning Poker. It is basically a deck of cards with estimates on the cards. There are 4 different colors, so 4 people could be estimating at any given time with a single deck.

Whatever method you use, make sure you work for the group's agreement and try to keep things fast-paced.