Category Archives: Product Backlog

The Gorilla Product Owner: It takes a village

Posted on by
Reply

“Bob,” Jake’s tone was almost plaintive. “You’re killing me here. I thought we had this all sorted out. Didn’t we just spend three days doing ideation work?”

Bob looked pained, he wasn’t happy and it showed. “We did and I thought we were sorted as well.” He gave a shrug, “Sales got wind of the requirements and threw a royal fit that we weren’t addressing performance on the OutDate hardware.”

“They do realize it’s a fifteen year old platform?”

Bob nodded, “And they insist it’s a must have to support ‘key’ customers.”

Jake grumbled, “fine, that explains that. What about this other stuff?”

Bob winced, “My boss isn’t happy with the strategy, he wants to alter course.”

I glanced over the new proposal. I made a note to talk to Bob about the concept of the word ‘alter.’ This plan was nearly a 180 from the previous one.

Jake threw his hands up in the air, “I give up. Every time I think we’re settled and I can start planning, the entire model changes again. Who the hell is in charge of the business plan?”

I could see Bob stiffen at that one. He didn’t respond, even though I could see he was rankled by the comment. I think he didn’t respond because he knew he really wasn’t in charge, even if his job description said that he was in charge. He had tried to put together a business plan and now, every time he turned around, someone was sticking a hand in and changing it.

“Sounds like you need to start the project before you start the project?”

“What is it this time, Hogarth,” I asked with no small amount of dread. Turning to face him I continued, “I’ve got Bob fully engaged with development, they’ve been meeting regularly. I’ve got an honest to goodness PO led product backlog for the first time ever.” I waved at the business plan on the screen, “and it’s all been tossed out the window. What’s the point? We are halfway through development and this is a huge shift in direction.”

Hogarth nodded, “Which is why you need a project before the project.”

I blinked, “Wait, what? That’s Big Design Up Front! We’re agile here!”

Hogarth gave me a huge, ivory filled yawn. “We covered this already, remember? Garbage in, Garbage out?”

I pointed a finger at Hogarth, “look here, I did that. Bob went through the whole process. We even brought in Jake and his team to look at some of the requirements. Our backlog was built on real requirements this time!”

Hogarth nodded, “And who else helped?”

“Huh?”

Hogarth gave a long stretched before fixing me with his dark gaze again. “You wouldn’t design the features without the agile development team, why design the business plan without an agile business team.”

Blink, blink. Well dang…

 

 A Product Owner is Not an Island

Experienced agilists will of course be saying “duh” right about now. Product owners are supposed to work with the team and collaborate towards a final product. This is good and effective, and the PO can still be an island if they do this. He just has seven other cast-aways, from his three hour cruise, on the island with him.

Beyond even the question of “how do you prioritize the business value of the backlog,” are questions like “what’s the business model,” “what’s the product concept,” and “where does the product owner get his requirements from in the first place?”

The product owner is not an island. He doesn’t sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone. Our product owner, still called a product manager by many companies, instead is sometimes reduced to nearly the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be “fast”, “ultra-secure” and “cheep.” The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks more like Frankenstein’s monster than Brad Pitt.

 That’s just the way it is, you can’t expect that to change.

 It can if you make a village.

In Garbage In, Gorilla Out I propose a new model for the early stage of a product. In what most lifecylces would call the Concept and Planning Phases I propose an iterative, agile driven, style that takes you from product ideation (vision) all the way to a well ordered backlog that the agile development teams can plan their iterations from. While I don’t speak to this in the GiGo blog, in essence, what I am espousing is an agile project where the finished product is a product or release backlog. So if GiGo is an agile project, where is the team?

In GiGo I briefly touch on the idea of the GiGo project team. It is not just the product owner that moves through the GiGo project. With her on the journey are representatives from her key stakeholders. This is not a fixed team and will vary from company to company. Ideally it won’t be more than seven, plus or minus two people which may require some team members to then go off and work with an SME team of their own. For example a representative from Technical Support might have their own Support GiGo team where they review and bring back final “product” to the primary GiGo team.

Who should be on the team? Other than the product owner, again it depends. Below is a list of common team members based on the most common roles to contribute to traditional requirements documents.

Product Sponsor Customer  (or voice of the customer)
Related product managers Technical Support
Technical Architect* Marketing
Agile coach or Facilitator Sales

While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO’d at them.

Do you have your village?

Garbage In, Gorilla Out- Know "What" before "Do"

Posted on by
1

“What do you mean he said it’s crap?!?” Jake’s voice thundered. I’m pretty sure there was steam coming out of his ears. I could feel my own kettle on a rapid boil myself so Jack must have been at nuclear meltdown stage.  I turned and cast a sympathetic eye down the table. Poor, Bob, our hapless product manager looked like he’d just been served up as the main course at a great white shark feeding frenzy.

I’ll give him credit though; Bob didn’t cower in the face of our rampaging development manager. I mean after all, it wasn’t his fault, he was just the messenger. Bob nodded his head gravely, “he did. He went on to say it was lifeless, had no vision, was poorly put together and had no business being on the store shelf.”  Ouch… Fiat Armburger was the man. If he gave your product a pass, you could name your price with the channel. But if he panned you, might as well start selling the office furniture now.

Jake shook his head, a look of complete disbelief washing over him. I don’t think I’d ever seen him look so defeated. “We executed perfectly. We even shipped three months early. Hell! We delivered everything you asked for in.” His eyes turned back to Bob at the last words.

“I know, I know,” said Bob. “What can I say, we missed the mark. We’ll just have to try harder the next time.”

I jumped to my feet. “Well now,” I interjected, because if I didn’t Jake was going to levitate across the room and kill Bob with his eyeballs alone. “We have a stack of bug reports here. Bad review or not, we’ve got to fix these issues before GA. After all, we still have to ship, the schedule is committed.”

It worked, everyone calmed down and we got back to making the product ready to ship. I don’t know about anyone else, but all I could really do is wonder whether anyone would even buy it.

“Nope, it’ll be the worst launch since Ishtar.”

Great, just what I needed. A failing product and now a gorilla who thinks he’s a movie buff. Why me?

“Well cause it’s your fault.” Hogarth offered up.

I spun my chair to face my personal gorilla. He was lounging on the wall contemplating his naval (yes gorillas have belly buttons, Hogarth’s was large enough to misplace loose change in). “How on earth is it my fault?”

Hogarth looked up, producing a quarter from his naval. “Well technically it’s Bob’s fault, but come on doesn’t it get boring always blaming  the product manager?”

“Hogarth, explain to me how this is my Bob’s fault much less mine?” Though the idea of it being Bob’s fault was certainly more appealing to me.

Hogarth smiled, “G.I.G.O.” 

“I… what… ” I stammered. Then my mind realized what he meant. “Oh… my george…”

 

Garbage In, Garbage Out:

GIGO is a term that reaches back to the dawn of the commercial computer age. It’s a fundamentally simple fact that states  “computers  will unquestioningly process the most nonsensical of input data (“garbage in”) and produce nonsensical output (“garbage out”).” The overall concept goes back even father to early “computer” inventor Charles Babbage (now seeing a resurgence in fame thanks to the Steam Punk phenomenon) .

It’s hard to argue with the concept, in fact the software programmers I know wouldn’t even try. To them it’s like trying to say “Brick+Music=42”. It just doesn’t work. You have to use good inputs if you ever want to have good outputs.

So then, why the heck do we think the magic solution is in the development soup?

For the sake of this discussion, we’re going to take a scrum team. This problem applies to any kind of development process, from BDUF to XP. I’m using scrum because let’s face it, some of us have held it up as the golden ticket to solve all ills. So let’s see what happens when the golden ticket uses lead to develop.

The official Scrum Guide is seventeen pages long. Of those seventeen pages, about one page is devoted to the concept of a Product Backlog. This page covers that the product backlog is the Product Owner’s responsibility, that it is important, that higher stories have more details, that it should be rank ordered and that it should be regularly groomed.

You can groom a Canadian Hairless cat all you want, he’s still not going to win any beauty contests. A scrum team needs a good product backlog (requirements) to work from. If they don’t have a good backlog, then  they can ship the project on time, on budget and it will still fail because it was a bad idea to start with. New Coke failed because there wasn’t a need for it, everyone was happy with the old coke.

GIGO– If you don’t take the time to figure out what you want, then you won’t get it.

But, but that’s not agile! You’re saying I have to do big planning up front! See I knew agile was a crock.

Yeah, no…

You don’t have to document the Library of Congress, before you start a project, but you need to make sure you at least understand what the customer wants and have an end vision in mind. You then have to make sure that when the developers are getting ready to start coding, they understand EXACTLY what is wanted for that functionality. You can absolutely be agile in your product planning process. In fact, you can just be agile in planning and I think you’ll get a better project, even if development still builds in “waterfall.”

The Gorilla Planning Outline:

I found much of my inspiration in Jim Highsmith’s Agile Project Management: Creating Innovative Products. I heartily recommend the book for anyone involved in project planning or project management. Another good bit of inspiration came from Agile Learning Labs, a really great agile coaching and training shop in the San Francisco Bay Area. If I have stood farther, it is because I have stood on the shoulders of giants (Isaac Newton).

Note: This is an outline only. Within each stage I promote agile based exercises to get to the end goal.

The Cast:

Product Manager/Owner

Product Sponsor

Customer Voice/Representative

Architect*- Optional

Agile Coach/ Facilitator

*- An architect level technical person can provide valuable insight to this stage of the project. It is vital though to ensure this person(s) can separate business from technical constraints. An architect who is constantly focused on the how and how long will not add value to the process during this stage. The exception is in Stage 6, Estimate the Cost.

Stage 1: Defining the Product

Purpose: Create the “product box.”

Time Needed: Half Day

Description: Ensuring everyone thinks that blue is really blue is a fundamental starting point. If the product owner things you are building a Ford Pickup and the Sponsor is envisioning a Land Rover, you have a disconnect. This stage of product planning focuses on the overall corporate goals and customer “box” experience. The “box” experience is the level of experience you get when you pick a product up off the shelf and look it over. What compels the customer to buy? The core of these concepts comes from Jim Highsmiths’ chapter on Envisioning from Agile Project Management.

Stage 2: Layout the Product Story Outline

Goal: Create a timeline of the product’s use and identify missing gaps.

Time Needed: Half day to full day.

Description: “How did we forget that feature?” has been a long asked question, typically so far into the development process as to require derailing the project to get the feature in. Story Mapping is a process that discovers the users, the end to end experience and then allows you to drive into the highest level of user stories but doing vertical break downs.

Stage 3: Create the Chapters (User Stories)

Goal: To create clear and concise descriptions of user experience with the product.

Time Needed: Oneweek offline work, after Stage 2 and then half day.

Description: A poorly written user story can lead to the implementation of something that is technically perfect and a complete failure as it doesn’t meet the needs of the user, as envisioned by the product owner. A critical component of this stage is that even the highest level stories need a basic acceptance test to validate against.

Stage 4: Decompose the User Stories

Goal: Break large user stories down into iteration obtainable goals.

Time Needed: Half day (can be done with Stage 3 to save some time overall)

Description: One of the largest challenges in the creation of a backlog is to go just far enough with the details of a user’s experience and not to far that you’re creating a functional feature spec. Product Managers often struggle to not provide so much data that they are directing the engineers to a specific implementation – which can both stifle a creative new idea and can upset the engineers who feel they are being dictated to. Engineers who get too vague a story are faced with many challenges, not the least being “what exactly are we building,” “If I’d know that originally, I would have estimated this as a much bigger story,” and “This will take at least six weeks, I can’t do it in a four week sprint.”

By breaking user stories down to iteration manageable levels the team is able to better estimate value and cost (time to complete), removes confusions that can result in a feature that doesn’t match the vision of the product owner, allows for shorter iterations – which itself improves the overall development process by allowing more chances to apply the “inspect and adapt” philosophy of agile.

Stage 5: Value the User Stories

Goal: To create a relative ranking of all user stories on a project.

Time Needed: One to two hours

Description: P0, P1, P2 ultimately breaks down. Fifteen years ago I never even heard of P0 and you might actually see a P3 in a product. Today you see projects where everything is a P0 and engineering says it will take two years.

Doing force ranking, feature weighting and other traditional techniques rarely leads to the level of consensus required to create a final ranked list. The realistic question to ask teams, at this stage, is how often estimating against real world artifacts has worked. When was the last time a product forecast was accurate? Using agile values opens up the process to creating a system that creates agreement not conflict.

NOTE: This is one of the secret sauces of this process. In my next blog I document an excellent exercise for how to define business value for an entire release in just a couple of hours.

Stage 6: Estimate the Effort (Cost)

Goal: Rank the user stories in relative order of effort (cost to produce).

Time Needed: One to two hours

Description: Classic estimating of user stories. It needs to be done on even the grossest level stories for the product owner to be able to properly rank order the backlog. Otherwise a backlog can be skewed towards value, costs or even worse, gut judgment. Poker Planning and Delphi models have an inherent flaw of focusing on the story itself which leads to exact effort and not rank ordering estimates.

The Cast: This stage does not involve the product owner/stakeholder cast. Effort estimating is done by the engineers doing the actual work. It is important to not just have management at this stage but engineers doing the functional work.

Note: The developers should not have knowledge of the business value rating at this stage. They are just assessing the complexity of the future. If they know a particular feature is the absolute silver bullet, they may over or under estimate it.

Stage 7: Order the Requirements List

Goal: One backlog to rule them all.

Description: At this point the Product Owner has both a business value and a cost. These are both placed on the user stories. From here the product owner then uses their judgment and skill to create the product backlog. They weigh the value and cost of a story (feature) to create the backlog.

Note: In agile development, best practice is to groom the backlog once iteration with the product team. This is where cost can be reevaluated, better definitions of stories can be done and the product backlog reordered as a result.