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/or the 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:
- 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:
* 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.”
- 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”).
- 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:
* 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.”
- 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.
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.
Posts
