First time planning poker – review

Today, we’ve had our first planning poker game involving 3 developers (one of them an architect) and myself. The architect who also performs local project management role had told me he liked the idea and it helped with the estimates however I still want to outline some of the things that caught my eye

  1. We have tried to estimate tasks and not user stories while in theory planning poker is used for estimating user stories that carry a certain business value
  2. The user story we have been referring to is actually an epic and should probably be decomposed into a set of smaller stories
  3. Instead of using 1 point as a “perfect developer day” we have tried setting a smaller scale – 1 point being equivalent to 4 hours of work
  4. Guys who are not familiar with the subject have been reluctant to provide their input on the estimates.
  5. Differences in estimates is what’s causing the discussion and the actual brain work. I saw that happen and saw how a person’s explanation of his position on the provided estimate (that was significantly higher than anyone else’s) was sound enough to bring everyone to the same conclusion
  6. It seems that generally, teams who have been working together for some time, tend to give estimates in a smaller range i.e. in the game today I haven’t seen deviations of more than 2 points

In the books on Scrum, Agile that I’ve read, the authors described that in planning poker games, the team or a scrum master just read out the story and start estimating. It does not seem to work well for highly specialized projects like our own where different individuals deal with different part of the business domain. As a result, we have 1 or 2 team members capable of making reasonable estimates and actually deliver what’s needed in specific areas like SCORM. Others, who don’t possess the same knowledge as these folks do, are less involved into explaining their position and wait to hear what more experienced members say.

Overall, it was a pretty cool experience and I look forward to introducing it on a sprint level for 1 or 2 of our subteams


QA+BA Sandwich – getting to the meat of user stories

Right now, this is just an idea I would like to research – more specifically, how to put together QA and BA work at the user story writing phase. My assumption right now, is that we can start testing before software is built and before it has actually started being built. The only problem is that I don’t know how exactly that should work.

Focus Factor – I am gonna come and bite you in the ass

A very important mark:

Scrum actually speaks about a phenomenon of “focus factor” (reads FOUKAS not FUKUS). This is quite important to grasp as we can relate it to our work. Focus factor (up to 100%) means the commitment a team or a team member has to a certain task. Let’s say, besides working on this specific task, a developer needs to fix certain bugs or implement some customization tasks for other customers. If the amount of time needed for those tasks is approximately 1/3 of the developer’s time, we can say that the focus factor for a specific task is at 70%. That means that if a story has 5 point and you plan to finish this task by Friday, starting Monday, reality will most likely bite you in the ass. With focus factor of 70%, a 5 point task would most likely take 7.15 days. We are living in the grave time so I would add up some pessimism factor and put 8 as the actual estimate.

About to lose my planning poker virginity

So far the first planning poker session is scheduled for Nov 26, 2012. My purpose is to explain the rules to the team, take a selected story and try to get estimates from all of the team members.

The estimate is in the form of  storypoints – simple numbers starting from 1/2 (I know, that’s not really a simple number) and the values assigned to a specific story describe the entire level of effort for a user story. So this is not just development effort but a combination of needed work in terms of design and architecture (if it’s on a project level), coding, testing.

Planning poker should not run for more than 3 rounds per user story. If it does so, some things may have to be changed or a more experienced facilitator needs to be found to explain the rules.

I am adding a couple of videos made by Aussies to explain the game

First video with a funny accent

Video from Mike Cohn (agile guru)

In a way this is like poker without having the antes placed by the two players before the start of the game. The dealer (oops the facilitator or product owner or scrum master) starts by reading out the user story or task that should be estimated. It looks like, in general the practice is to do estimates for ALL of the stories planned for a sprint. This is where the change is for us, as we will start from a single story.

The story we are planning to discuss is actually a sub-story so we probably need to determine where this story ends and what are the acceptance criteria for it.  Just a few lines on the board or on a card.

Before everyone starts screaming and yelling why his or her estimate is better, we need to set some sort of a baseline. Baseline in this sense is to specify a simple story/feature worth of 1 or 2 points that everyone agrees on..

Pending item: Need to get the input from guys on a very simple feature. Let’s say, getting the browser to ask users if they really want to leave the page with unsaved content. Level of effort should include estimates for the specific text for the message, implementation of this feature and QAing it. If we decide this is a 1/2, so that means when assigning 5 story points to a story, we speculate it would be 10 times more complex than the baseline story.

After the dealer voices the story statement and all of the team members are given the cards, the first round of betting starts. Every person betting can only use 1 card to bet. Possible values include

  • 1/2
  • 1
  • 2
  • 3
  • 5
  • 8
  • 13
  • 20
  • 40
  • 100
  • INFINITY (not car)
  • ? – equivalent to “HZ”

Next, everyone look at the estimates and tries to figure out why the hell no marks coincide. This is (in theory) where the fun begins as someone can assign 8 and someone else can assign 3. The facilitator asks team members why the opinions are so different. It may be that someone is overestimating or underestimating the story. That bastard needs to be found and punished! Just kidding. It’s a very good thing as it helps to think of something that could have been missed otherwise like those freaky nested groups we have been fighting with in the past few weeks.

Then, the story is read once again and the second round of betting starts. This time we either get closer marks or see that we have a troll in our team. That bastard also needs to be punished!

Eventually, by trial and error this should somehow work.

Planning poker – where to start

After reading (well, technically while still reading) Henrik Kriberg’s book “Scrum and XP from the trenches” I realized I really would like to try something like planning poker. Recently we’ve had somewhat of a mess with one of the features we are building and while eventually it should come out nicely, there have just been too many rocks we’ve stumbled upon. Now I am thinking that perhaps we really should change or at least define a way to make estimates for the features we are building and if planning poker works for so many teams, why the heck it should not work for us?

I’ve downloaded a few videos about the game and am trying to figure out how it’s done and what problems may arise if we try the game.

So what I have so far:

  1. A collection of paper cards with values 1/2 all the way to infinity that I’ve printed out and carved with my big paper knife (not so nicely). The pdf version of the cards I have found on this site and they are free. I could have actually drawn my own cards and probably that’s what I will eventually do as I don’t really want to spend $15 on this
  2. Four developers and myself who will be involved (I will just watch and coordinate)
  3. A user story that needs to be implemented. The problem is that the story is going to be broken in a few sub-stories and right now we are only estimating the first one
  4. Some vague understanding of what a story point is and what it correlates with. Most of sources mention that a storypoint is not really about time but about complexity of a task which is a bit weird to me as complexity still can be expressed through time (just more time)
  5. Some vague understanding of the purpose – probably trying to make estimation more down to earth and transparent for all team members

What I don’t have yet

  1. An understanding of how to deal with individual differences i.e. if the level of team members estimating the task is different. If one person marks a story with 3 points (i.e. would require approximately 3 perfect days to complete) while the other person marks at 5 – what should be takes as a baseline?
  2. What does the card with the person’s estimate actually entail?
  3. How to actually select a baseline?
  4. if this does not work from start, how many times may be needed before this technique actually helps?
  5. Will guys hate me if this does not work?


Hello world!

I am working as a Business Analyst on a VERY distributed IT project. While the company is not very big, it has a number of people in various locations working all over the world. Surprisingly enough, this model works well for the company while 80% of all interactions between team members are virtual!

At the same time, I am able to work with folks from Czech Republic, US, Russian Federation, Spain, Macedonia, Costa Rica and of course my fellow team members here in Lviv, Ukraine!

With this level of virtual communication, everything has to be extremely formal or as little formal as possible to keep communication live.

The management decided, “as little as possible” should work just fine and this is how we’ve come to adoption of Agile methodology. Our Agile is quite dirty but it works. My goal now is to try and see what can be done (at least in my own team) to improve the way things are done. In this blog I intend to write down my thoughts on what worked and what did not.