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.
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.
- Place Story Cards in pile on table.
- First player places top card on playing surface.
- 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.
- The third player then has several choices. They can either:
- Repeat Step 4 until
- 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.
- Place the “1” Card over the left most story. This story now represents your baseline that all other stories are measured against.
- 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.
- The third player, then has several choices. They can either:
- Repeat Step 4 until
- All stories have an assigned value (not all Fibonacci cards must be played), and
- All players pass on adjusting any of the Fibonacci cards.