Category Archives: Estimating

Don’t play Planning Poker with the Gorilla

Posted on by
2

“10 Days” Eric said.

I sighed. “Eric, you’re supposed to use the planning cards and put down a value.”

As he flipped through his stack of cards I could see him counting to himself. “Okay, fine. I think this is an 89 point task”

Sigh… “Eric, you just counted out ten cards and put that card down.”

“Yeah, so?”

I leaned forward and tried to use my calmest voice. “Eric, we’re not trying to figure out how many days right now, we’re trying to do an abstract estimate on the relative size of each story in the whole project. “

He waved his hand, “What’s the point? If we’re painting a house and you ask me to estimate how long it will take to paint the garage door I can put down a 2 or just tell you two hours. You’re asking me to use an abstract number when I already know how long it will take.”

I sat back in my chair perplexed. The problem was that I could see his point. We were tackling each task one at a time and no matter what I did, I couldn’t break the team out of thinking about how many days something would take. And I knew this was a slippery slope that led back to padding, swags and a whole slew of inefficient planning practices.  

A long meeting later I dragged myself into my office. Only to find both my chair and the guest chair occupied. One of the occupants I expected to be there, a post meeting debrief on this last meeting was much to much for my personal gorilla to miss. Seeing the black swan flipping playing cards onto my desk was quite another thing.

Flip, flip, flip “144!” Hogarth said, triumphantly.  Looking at the black feathered swan he grinned. “Hah, that beats your 21.”

“Hogarth!?” You’d think I would get tired of yelling his name. Or maybe I would just get used to his ever present level of restrained chaos. You’d think… “What are you doing with my Planning Poker decks?”

“Oh, hey there,” Hogarth turned his cheerful smile my way. “Wanda and I were just playing war.”

Tossing her last card, a 2, down Wanda slid off the chair. “I have to get back to the server room anyway, one of the HVAC’s is about to short out because a gopher climbed on the roof and ate through the power cable.”

Trying not to think of electrocuted gophers and overheating servers, I ignored the departing black swan and turned my attention back on Hogarth. “Why are you playing war with my Fibonacci cards?”

“Oh, that. Well I figured you might want them and then we just kind of got bored waiting for you to be done not estimating the release.”

I blinked at him. “Hogarth, I know you were eavesdropping on the meeting. You know perfectly well the team thinks planning poker is useless.” I tossed myself into the vacated guest chair with a sigh. “And I’m not sure I don’t disagree with them.”

“Since when have you believed there’s only been one way to use a tool?”

Blink, blink… Why did he always have to be right?

 

Story Point Estimating

This is one ofthe foundational principles of Scrum software development (and Agile  in general). Done well, story estimating can create an incredible level of predictability and transparency. A high performing team can look at a set of requirements and provide a high confidence assessment of when they will done.

But this isn’t about the value or use of estimating. There is plenty written on this and I’m not here to rehash it. I believe in estimating, just as I believe in the principles of agile and good management.

What I’m here to say is I think Planning Poker is the wrong way….

What? Come on, I’d be a lousy gorilla talker if I wasn’t willing to tackle tough subjects head on. I do absolutely think story point estimating is the right thing. I just think planning poker is not the best way to do it.

Naturally this begs the question of “why?” I have two reason for my concerns on the use of planning  poker:

  1. Each user story (feature, tasks, item) is evaluated on its own. When you do planning poker you are just looking at how long it will take to paint the garage door. You are hard pressed to look at it in relation to putting a new latch on the back gate. I think the mind is hard pressed not to assign a physical value to the estimate. “I think this will take two hours, that’s about a 3.”
  2. At the end of the day, the planning poker process occurs in an individuals head.  Yes, there is a discussion among the team, but only after each person has drawn a line in the sand. Once the human mind draws a line, it finds it hard to move that line. We’ve invested ourselves in that line.

So what the heck do you do?

Well if you’ve been following my recent agile related blogs, you’ll know I’m a very big fan of something called the “Team Estimation Game” developed by Steve Bockman. I personally like to call it “Team Planning Solitaire.” The style of the game reminds me of classic Klondike solitaire and the interaction of the team makes it anything but a solo activity (what can I say, I like irony). I will also note that while I learned this from Steve Bockman and Agile Learning Labs , I have seen some similar exercises in the last few months. Whether they are parallel development or evolutions of Bockman’s game, I don’t know.

I detailed how this game worked in “How much is that Gorilla in the window.”

At the highest level, the process starts with the story cards in a pile. Each person takes a turn laying out a new card or moving an existing card on the table. At the end, you have a line of cards in rank order. Only then do you break out the planning poker cards. Your estimates end up being based on the relation to the other stories, not to how long one story will take.

Why is the Team Estimating Game so good?

  1. Stories are estimated in relation to one another and not in a vacuum. “Is painting the garage door more or less effort than replacing the latch on the back gate? All right, is painting more or less effort than rehanging the front door.”
  2. It’s a team activity. Nothing happens in anyone’s head. It is all out on the table and very straight forward. You aren’t sitting there arguing that the Database re-architecture will take a week or two weeks. You are just trying to decide if it is more or less effort that localizing the user interface to Japanese.

At the end of the day I think Team Estimating is much more effective than planning poker. Leave the poker cards for a nice game of Klondike or Texas Hold ‘Em.

Who’s ante is it?

 

 

How much for that Gorilla in the window? – Assigning value to requirements

Posted on by
Reply

Hogarth shoveled another handful of popcorn into his mouth (Yes, gorillas like popcorn – read the right sidebar, go figure). He was sitting at the end of the table, size huge feet propped up on the table and looked as if he were thoroughly enjoying himself.

Which couldn’t be said for me. I turned back to the discussion at the table, wishing a crack in the earth would open and swallow me up.

“Every one of them is a P Zero feature.” said Tully, the junior product manager. Though I swear I could see Bob’s lips moving as Tully spoke.

We were in the Icarus project’s concept phase exit meeting. Product management had just presented their list of requirements for Icarus. The entire list was up on the projector screen, two columns wide and in ten point font. I had surreptitiously taken a photo with my phone and was zooming in just so I could read the list.

“But which one is the highest priority?” Jake asked. This meeting was where engineering saw the requirements for the first time and started looking at what could be done. Feeling like I was in a tennis match, I let my eyes swing back toward the two product managers.

“All 100 features are must ship, they are the same priority.”

I was starting to feel like I was witnessing the start of a train wreck and there wasn’t a damn thing I could do about it.

“Look, even if we could do all these features in the release, which we can’t, you still would need to prioritize them so you can flesh out the top of the backlog. None of these are good enough to start developing on.” Jake was keeping his voice surprisingly calm.

Bob had apparently gotten tired of the ventriloquist act and spoke up. “Are you saying you’re only going to estimate the top items?”

Jake sighed, shaking his head. “No, we can give you a relativistic estimate on everything, with this data. But none of these features is defined enough for the team to start work. I’ve got no idea what to start on in the first sprint.” He laid his hands on the table, “Look, if you can’t prioritize them then you have to do full user stories on all of them and I’ll just pick which one to do first. That’s fine by me.”

“But we can’t do that, it would take weeks to flesh out all these features, and besides the requirements might change.”\

Jake shrugged. “Then we need to find a way to rank order them. I can do effort estimates on all of them and just start on the easiest ones first.”

Oh boy, Jake was playing hardball now. Bob leaned over his laptop with a pained expression. “The easy stuff isn’t what the customer wants right now.”

Jake leaned back. “Well at least we’re getting somewhere.”

At this rate, this was going to be a long meeting and it wasn’t going to solve anything. Against my better judgment, I turned to cast an imploring look at Hogarth. Wiping his popcorn encrusted mouth with the back of a furry arm, he reached into the popcorn bucket and pulled out a deck of Fibonacci cards.

“It works for story points…” He offered.

 

What do we do first?

Today we talk about one of the fundamental problems with product requirements. Last week’s“Garbage In, Gorilla Out”focused just on the need for good requirements. This is important, vitally so. A well executed project, built on bad requirements is a bad product (Can you say HP Web Tablet? I knew you could)

The problem is, then what?

If I have one hundred perfectly defined features what do I do with them now? I can hand them off to the development team so that they can give me a level of effort (Story Points in Agile). That’s great, but now I have one hundred perfect features with story points. I still don’t know which one to do first.

Business value: What is the value of this benefit to the customer and/orthe business? This can also be asked in reverse, “what will it cost us to not implement this?” (Kanban tends to look at it from this view point). If you don’t know what the value of the feature/user story then you don’t know if it is more or less important than the next feature. You then end up in the model some old style engineering managers love. “Just give me the list of what you want, I’ll figure out what I have time to build.”

Technically perfect and customer flawed.

Apple has constantly focused on the value. Products they delivered did exactly what you wanted them to do (sometimes even doing things you didn’t know you wanted, but now can’t imagine how you would ever live without). Being a PC guy, this has sometimes been a hard pill to swallow. I’ve seen the exact opposite with PC products. “Do I really need 7mm instead of a 9.5mm hard drive? What I would really like is it if it included Bluetooth so I didn’t have to have a separate set of headphones just for my computer.” PCs have been really great at offering up new features that had no real infrastructure to use right away while lagging on basic,s like user interface.

Great, I’m sold already, how?

Ah and there in lies the rub. How do you figure out business value? Raise your hand if you’ve seen a product management forecast you believed in. Yeah, thought so. So if we have trouble figuring out how much we’ll sell of the whole product, then how do we decide the value of a single feature/user story? Some companies have put together very elaborate procedures for this that practically call for a Ph.D. in math. Reportedly Intel has eighteen value “levers” used to evaluate not just projects but features in a project. Yikes.

Reaching into the agile pool isn’t a lot of help either. While a whole blog of its own, the core issue with the most common estimating technique,Planning poker, is that it focuses on one feature at a time. And the problem with that is the human mind. Say I’m playing planning poker on a home improvement project. The user story is “As the home owner I want a blue exterior because it will make my house blend in with the skyline.” Okay, painting the house. No matter how hard I try I’m going to be thinking about how many hours I’m going to need. When I flip over the 13 I’ve just mentally associated three days with 13. So of course a one day project is a 5, right?

When you evaluate each feature on its own, it is very hard for the human mind to not associate time with it. 

So don’t…

Steve Bockman developed an estimating process called “The Team Estimating Game.” He and Agile Learning Labs have been using the game for years, teaching teams and companies this new way of estimating story points. Last year, Agile Learning Lab’s maven Laura Powers realized that it could be used for assigning Business Value. 

And?…

And with permission of Agile Learning Labs, I’m sharing their excellent game. After attending a Product Owner Training, I wrote down what I learned and have been using it ever since.
The Exercise:Take the defined user stories. These can be at any level of detail, but obviously it is better if they have some basic story decomposition done and they are clearly understood by the product owner and other business stakeholders. It is best to start with no more than twenty stories. After completing the game with these stories, future stories are then played against this initial set of stories. This makes subsequent evaluation go quicker and allows for estimating the value of hundreds of stories.
Phase 1:The first step is to estimate their value relative to each other:
  1. Place Story Cards in pile on table.
  1. First player places top card on playing surface.
  1. The second player places the top card on playing surface relative to first card. They decide if the card is worth more business value or less than the original story.
  1. The third player then has several choices. They can either:
* Play top card from pile, placing it on the field where they think it fits (moving other stories to fit between stories as needed), or
* Move a card on the playing surface from one location to another, or
* Pass
Note: When placing or moving a card the person conducting the action typically gives a short explanation. So long as it does not derail the conversation, team discussion is  encouraged. The Agile Coach/Facilitator monitors this and if a conversation starts to deep end they ask “So whose turn is it now.”
  1. Repeat Step 4 until
a) no more cards remain in pile, and
b) no player wishes to move a card
At the end of the first phase of the game you have a single, linear line of user story cards. The cards to the left are deemed the least valuable and the cards to the right are the most. No overlap of cards occurs at this time.
Phase 2:Having ranked each story to create a single ordered list, it is now time to assign a value rating.
Start with a standard deck Fibonacci numbers. Typically up to 144 is more than sufficient. Add to this the (-) card, to represent stories that have no business value. Note: Business value may not represent the only value in a project. You may have regulatory concerns, infrastructure concerns, etc. Whenever possible try to assign a business value to the story. This usually requires looking at the operational This may require asking the “what do we lose if this is not here?” Zero business value should be truly something that will not be missed in anyway if it is not in the product (“No one really wants a wood stove in their car”).
  1. Place the (-) card to the left of the left most story. Anything that moves left of this card will be considered of no business value.
  1. Place the “1” Card over the left most story. This story now represents your baseline that all other stories are measured against.
  1. Hand the deck to the first player. The player takes the “2” card from the deck and then looks at the stories to the right of the “1” card. They place the card at the story they think is twice as valuable as the first story.
  1. The third player, then has several choices. They can either:
* Place the “3” card to the right of the “2” card where they think a story is either three times more valuable than the first story or is one and a half times more valuable than the story with the “2” over it.
* Move the “2” card left or right to where they think the user story is equal to twice the value of story one.
* Pass
Note: Fibonacci Cards are placed on the table in order. You do not place the “21” card until the “13” card has been placed.
Note: Any stories between Fibonacci cards are assumed to belong to the Fibonacci number to its left. So if there are three stories between the “5” and the “8” then it is assumed those three cards are considered a value of “5.”
  1. Repeat Step 4 until
    1. All stories have an assigned value (not all Fibonacci cards must be played), and
    1. All players pass on adjusting any of the Fibonacci cards.
Concluding:At this point any “orphan” cards, those between Fibonacci cards, are then moved into columns below the Fibonacci Number to their left. You are now left with a number of columns of cards (there is no right number).
The exercise is done. Capture the value for each story in the appropriate manner.
Important Note:The Coach/Facilitator should watch for ranking based on cost. This exercise should be conducted with the “infinite budget” concept. “Don’t worry about how hard it is to build right now, just worry about how valuable it will be.”
Important Note:If you are planning to have these stories estimated for cost (time to develop), it is recommended that the business value not be shared with the team doing the cost estimating. This prevents the cost estimating being skewed by the Business Value.