First I need to start off by saying that my experience is related to combining planning poker with agile development. For me this is Scrum. For planning poker to work I believe you need to use commitment driven planning as part of your sprint or iteration planning. I think that without this, planning poker will not be equally efficient.  One of the tools a team has in agile development is velocity, so let me first explain velocity.

Velocity is the average amount of story points your team successfully has committed to over one or more sprints. A team’s velocity will evolve over time, and be more and more accurate if you can:

1. Keep the number of members in your team stable
2. Have the same length on all sprints
3. Keep doing the same estimating mistakes

If you change either one of these, you will weaken your velocity. Here are some examples of the above:

1. By removing a member from your team, you will not be able to do as much work as before, resulting in a sprint with fewer story points than in previous sprints.

2. If you have a shorter sprint than your normal sprint length, you will be able to commit to less story points which gives a wrong outcome for your velocity.
3. If there is a sudden increase/decrease in the amount of story points estimated for a user story compared to a previously similar user story, the velocity will be less accurate.

One important thing about velocity is that it’s not necessarily this number you should use when your team is committing to user stories for a sprint. The velocity main purpose is to plan ahead for more than a sprint, e.g. for release planning. Typically the product owner uses the team’s velocity to calculate how much work can be fitted into one release.

When you sit down for a game of planning poker you focus on estimating user stories. Before you start a sprint the team goes through the estimated user stories and commits to do a certain number of these in the sprint. The first time they will probably miss by committing to too much. The second time they will do better and so on. Eventually the team will get a feeling of how much they can commit to. Remember what I said earlier, the team should not USE the velocity to commit, but rather use it as a warning sign. E.g. if the team commits to much more than the current velocity, you might want to check your commitment again.

So, back to estimation. If a team consequently estimates to low on their user stories, this will be corrected by how much the team is actually willing to commit to in the sprint. This is also indicated by the velocity. It’s much easier to control and to see when the team misses a sprint, than to keep track of all estimates and figure out which were estimated too high or too low, and try to learn from that. This also means that you can’t try this couple of times, see that it didn’t work, and give it up. You need to give it time.

It’s time for another NNUG meeting in Bergen. This time we’ve got Einar Ingebrigtsen talking about XNA and John St. Clair talking about continuous integration with TFS. This will be a great event! For complete agenda go to NNUG Bergen and sign up. Hope to see you there.

Are you an estimating guru? Have you never missed an estimate in your life? Can you even do estimates for others? Then this is not for you. However, if you don’t recognize yourself in the previous description this still might be something for you.
When I introduced Scrum to my organization, we quickly started to use planning poker. So what’s planning poker? Here’s what planningpoker.com says:

“Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again.”

How we use planning poker in Contiki

At Contiki we use planning poker to estimate all our user stories, or features if you want. When the backlog starts filling up with un-estimated backlog items, we gather the team for a round of poker. We also have a team in Ukraine, so using planningpoker.com works great for us. Here’s what we do step by step:

1. The product owner reads the user story and adds any additional information he think is necessary. No comments or input is allowed from the others at this time (our experience is that starting the table discussion before the first estimate takes a lot longer and will not make the estimate any better).
2. Everyone vote for an estimate.
3. When all estimates are in, all estimates are revealed. When we see that the estimates vary (which usually is the case), we ask the person with the lowest and the person with the highest estimate to discuss why they differ. This usually results in highlighting the different perceptions of the user story and helps clarify other aspect previously unknown to the story. The person with the lowest estimate might know something that will make implementation easier or the person with the highest estimate might know some other implications that the other person didn’t.
4. At this time other people might jump in to add extra knowledge to the story if they think this will help.
5. After a short discussion a new voting is started, if not the estimates are very close to each other that is.
6. If the estimates are still not the same, pick an average.
7. In rare cases we allow a third vote if the team agrees.

Using a team to do the estimates has several advantages:

• If one person is doing the estimate, it’s not definite that he’s the person to implementing the functionality, making his estimate less valid. I’ve never understood people doing estimate for others.
• If only one person does the estimate, he estimate is based on his background and his knowledge.
• Having several people with different experience, knowledge and perception to agree on an estimate, usually results in a better result. It will usually help people visualize aspects of a functionality that was previously unknown the one person.
• It’s more fun!

Later I’m thinking of talking about:

• The anchoring effect
• Story points vs. days
• Why does planning poker work?

I started
to answer Torbjørn’s
comment on my previous
post about general specialist, but it turned out to be far too long for a
comment, so I posted it hear instead.

I think I
did a poor job defining the general specialist. Actually, after doing some more
research I found that the guy I didn’t remember the name of was Scott W. Ambler
(which I’m a bit embarrassed of not remembering). Anyway, he actually doesn’t
call it a general specialist but generalizing specialist (or craftsman), which
is a better description. In my post I focused much on sharing knowledge. Sharing
knowledge is important, but what I didn’t focus enough on is that generalizing
specialists are also specialists in certain areas, but in addition to that also
has quite a bit of knowledge in other areas. What Scott is stating is that you
as an IT person should strive to become a generalizing specialist and not a pure
specialist. His examples are focused on a much broader scale (like use case
specialist, database specialist, C# specialist and so on). Torbjørn touched on this as well. What I’m saying is
that by putting the same principals to a smaller scale, where you have
developers specializing in certain areas of the application, you get the same
effect.

So I think
that developers should strive to teach themselves different part of the system,
and not specialize in a few areas. One way of doing this is to motivate
developers to share knowledge and allow them to work with parts of the system
that someone else might do faster because he’s the specialist in that area.

Torbjørn
commented on my previous post that:

“Nobody can be expert
of everything”

And that’s
not what I meant. What I meant was that people should be allowed to specialize
in areas outside their specialty to become generalizing specialists. This will
also let developers sharing greater knowledge within certain areas to be better
suited to improve functionality within this area. Two people think better that
one, right?

To hear more on this from Scott himself, check
out this
video. He covers a lot of topics in this talk, but if you forward to about
36 minutes, he’ll talk about generalizing specialists. Also check out his web
site about
generalizing specialist.

Found this typing test at Daniel Moth’s blog and thought I share it. My result was:

Number of words typed: 185
Test duration: 3 min
Speed: 61.9 words/min. (309 keystrokes/min.)
Error penalty: 15
Accuracy: 91.9%

I know I can do better when typing in Norwegian, which is my native language, and the error penalty was bad. But enough with the excuses. What’s your score?