Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

During this tutorial, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This 180 mins tutorial teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

Detailed Activity Breakup

1. PART 1: UNDERSTAND PRODUCT CONTEXT
• Introduction
• Define Product Vision
• Identify Users That Matter
• Create User Personas
• Define User Goals
• A Day-In-Life Of Each Persona
2. PART 2: BUILD INITIAL STORY MAP FROM ACTIVITY MODEL
• Prioritize Personas
• Break Down Activities And Tasks From User Goals
• Lay Out Goals Activities And Tasks
• Walk Through And Refine Activity Model
3. PART 3: CREATE FIRST-CUT PRODUCT ROAD MAP
• Prioritize High Level Tasks
• Define Themes
• Refine Tasks
• Define Minimum Viable Product
• Identify Internal And External Release Milestones
4. PART 4: WRITE USER STORIES FOR THE FIRST RELEASE
• Define User Task Level Acceptance Criteria
• Break Down User Tasks To User Stories Based On Acceptance Criteria
• Refine Acceptance Criteria For Each Story
• Find Ways To Further Thin-Slice User Stories
• Capture Assumptions And Non-Functional Requirements
5. PART 5: REFINE FIRST INTERNAL RELEASE BASED ON ESTIMATES
• Define Relative Size Of User Stories
• Refine Internal Release Milestones For First-Release Based On Estimates
• Define Goals For Each Release
• Refine Product And Project Risks
• Present And Commit To The Plan
6. PART 6: RETROSPECTIVE
• Each part will take roughly 30 mins.

I’ve facilitated this workshop for many organizations (small-startups to large enterprises.)

More details: Product Discovery Workshop from Industrial Logic

Techniques

Focused Break-Out Sessions, Group Activities, Interactive Dialogues, Presentations, Heated Debates/Discussions and Some Fun Games

Target Audience

• Product Owner
• Release/Project Manager
• Subject Matter Expert, Domain Expert, or Business Analyst
• User Experience team
• Architect/Tech Lead
• Core Development Team (including developers, testers, DBAs, etc.)

This tutorial can take max 30 people. (3 teams of 10 people each.)

Workshop Prerequisites

Required: working knowledge of Agile (iterative and incremental software delivery models) Required: working knowledge of personas, users stories, backlogs, acceptance criteria, etc.

Testimonials

“I come away from this workshop having learned a great deal about the process and equally about many strategies and nuances of facilitating it. Invaluable!

Naresh Jain clearly has extensive experience with the Product Discovery Workshop. He conveyed the principles and practices underlying the process very well, with examples from past experience and application to the actual project addressed in the workshop. His ability to quickly relate to the project and team members, and to focus on the specific details for the decomposition of this project at the various levels (goals/roles, activities, tasks), is remarkable and a good example for those learning to facilitate the workshop.

Key take-aways for me include the technique of acceptance criteria driven decomposition, and the point that it is useful to map existing software to provide a baseline framework for future additions.”

Doug Brophy, Agile Expert, GE Energy

Learning outcomes

• Understand the thought process and steps involved during a typical product discovery and release planning session
• Using various User-Centered Design techniques, learn how to create a User Story Map to help you visualize your product
• Understand various prioritization techniques that work at the Business-Goal and User-Persona Level
• Learn how to decompose User Activities into User Tasks and then into User Stories
• Apply an Acceptance Criteria-Driven Discovery approach to flush out thin slices of functionality that cut across the system
• Identify various techniques to narrow the scope of your releases, without reducing the value delivered to the users
• Improve confidence and collaboration between the business and engineering teams
• Practice key techniques to work in short cycles to get rapid feedback and reduce risk

Building on top of my previous blog entry: Version Control Branching (extensively) Considered Harmful

I always discourage teams from preemptively branching a release candidate and then splitting their team to harden the release while rest of the team continues working on next release features.

My reasoning:

• Increases the work-in-progress and creates a lot of planning, management, version-control, testing, etc. overheads.
• In the grand scheme of things, we are focusing on resource utilization, but the throughput of the overall system is actually reducing.
• During development, teams get very focused on churning out features. Subconsciously they know there will be a hardening/optimization phase at the end, so they tend to cut corners for short-term speed gains. This attitude had a snowball effect. Overall encourages a “not-my-problem” attitude towards quality, performance and overall usability.
• The team (developers, testers and managers) responsible for hardening the release have to work extremely hard, under high pressure causing them to burn-out (and possibly introducing more problems into the system.) They have to suffer for the mistakes others have done. Does not seem like a fair system.
• Because the team is under high pressure to deliver the release, even though they know something really needs to be redesigned/refactored, they just patch it up. Constantly doing this, really creates a big ball of complex mud that only a few people understand.
• Creates a “Knowledge/Skill divide” between the developers and testers of the team. Generally the best (most trusted and knowledgable) members are pick up to work on the release hardening and performance optimization. They learn many interesting things while doing this. This newly acquired knowledge does not effectively get communicate back to other team members (mostly developers). Others continue doing what they used to do (potentially wrong things which the hardening team has to fix later.)
• As releases pass by, there are fewer and fewer people who understand the overall system and only they are able to effectively harden the project. This is a huge project risk.
• Over a period of time, every new release needs more hardening time due to the points highlighted above. This approach does not seem like a good strategy of getting out of the problem.

If something hurts, do it all the time to reduce the pain and get better at it.

Hence we should build release hardening as much as possible into the routine everyday work. If you still need hardening at the end, then instead of splitting the teams, we should let the whole swamp on making the release.

Also usually I notice that if only a subset of the team can effectively do the hardening, then its a good indication that the team is over-staffed and that might be one of the reasons for many problems in the first place. It might be worth considering down-sizing your team to see if some of those problems can be addressed.

“I’m going shopping, can you please give me the details of everything you’ll need for the next year?”

What if I asked you this question?

Don’t just throw the mouse at me yet. You look extremely annoyed, but indulge me for a minute. Do you have any idea how much more you might spend because of your lack of planning? I’m sure when you run out of things, you wish you had planned better. After all good upfront planning is always helpful. Its Industry BEST PRACTICE.

Let’s assume, you are convinced with my logical reasoning and well-polished methodological approach to planning. You start creating a backlog of items you’ll need over the next year. And you start filling out the details for each item in a nifty little template I’ve given you. Of course its taking a lot longer than you imagined, but you are discovering (at least forced to think about) many things you had never thought about.

By the way, at the end of this exercise you’ll need to hand over a signed list to me and you can’t change you mind later. We don’t entertain change requests later as its more expensive. After all, we need to put some constraints to make are planning effective.

What, when, how, how much, etc. all kinds of interesting questions plague your mind. Making you realize how unplanned and clueless you were.

Perseverance always wins, in the end. Finally you have a backlog of items you’ll need for the year.

OK. Cut! Lights!

I bet one out of 2 things about the list of items:

• The list was very ambitious (massively grandiose.) You fantasied every possible thing you might ever need, just in case. (After all, what is the guarantee you’ll get everything you asked for.)
• You came up with a very humble list and since you won’t be able to change it cheaply, you regret now for indulging me.

Either ways its bad news for you.

This is exactly what happens on many software projects. Right at the beginning of the project, people who need the software (users or product management) are forced to come up with a detail spec of everything they need from the software. With a higher price tag for late changes. Which forces them to fantasize everything they might remotely need. After all, they are not sure what really will be required once they have the software year or two later.

The development team gets a pile of stuff with different priorities and importance, but all mixed up.

The team tries to come up with a grandiose vision and architect for the project in the name of extensibility.

Eventually, couple of years from now, somehow if the team manages to deliver the product:

• Its bound to be off target.
• Users will force the team to add new, unplanned features which are very critical for the usability of the product.
• A good 80% of the features are rarely used or never used.
• Those 80% of the features contribute to majority of the bugs and complexity in the software
• The overall product feels like a hotchpotch of “stuff”. Lack of symmetry and conceptual integrity

What you really have is a prototype that the team is ready to discard and start over again.

I call this phenomenon The Window of Opportunity. One opportunity, at the beginning, to express what you want. Take your best guess.

We can do much better than this. I would prefer to start really small, very focused. Use Agile methods to build the product collaboratively using an iterative AND incremental model. Embrace evolutionary design and architecture.

The Window of Opportunity *might* sound good in theory, but its too risky.

Recently TV tweeted saying:

Is “measure twice, cut once” an #agile value? Why shouldn’t it be – it is more fundamental than agile.

To which I responded saying:

“measure twice, cut once” makes sense when cost of a mistake & rework is huge. In software that’s not the case if done in small, safe steps. A feedback centric method like #agile can help reduce the cost of rework. Helping you #FailFast and create opportunities for #SafeFailExperiements. (Extremely important for innovation.)

To step back a little, the proverb “measure twice and cut once” in carpentry literally mean:

“One should double-check one’s measurements for accuracy before cutting a piece of wood; otherwise it may be necessary to cut again, wasting time and material.”

Speaking more figuratively it means “Plan and prepare in a careful, thorough manner before taking action.”

Unfortunately many software teams literally take this advice as

“Let’s spend a few solid months carefully planning, estimating and designing software upfront, so we can avoid rework and last minute surprise.”

However after doing all that, they realize it was not worth it. Best case they delivery something useful to end users with about 40% rework. Worst case they never deliver a thing or they deliver something buggy that does not meet user’s needs. And what about the opportunity cost?

Why does this happen?

Humphrey’s law says: “Users will not know exactly what they want until they see it (may be not even then).”

So how can we plan (measure twice) when its not clear what exactly our users want (even if we can pretend that we understand our user’s needs)?

How can we plan for uncertainty?

IMHO you can’t plan for uncertainty. You respond to uncertainty by inspecting and adapting. You start with sometime small (end-to-end) and rapidly build on it using user feedback and personal experience. Embracing Simplicity (“maximizing the amount of work not done”) is critical as well. You frequently cut small pieces, integrate the whole and see if its aligned with user’s needs. If not, the cost of rework is very small. Embrace small #SafeFail experiments to really innovate.

Or as Kerry says:

“Perhaps the fundamental point is that in software development the best way of measuring is to cut.”

Every day I hear horror stories of how developers are harassed by managers and customers for not having predictable/stable velocity. Developers are penalized when their estimates don’t match their actuals.

If I understand correctly, the reason we moved to story points was to avoid this public humiliation of developers by their managers and customers.

Its probably helped some teams but vast majority of teams today are no better off than before, except that now they have this one extract level of indirection because of story points and then velocity.

We can certainly blame the developers and managers for not understanding story points in the first place. But will that really solve the problem teams are faced with today?

Please consider reading my blog on Story Points are Relative Complexity Estimation techniques. It will help you understand what story points are.

Assuming you know what story point estimates are. Let’s consider that we have some user stories with different story points which help us understand relative complexity estimate.

Then we pick up the most important stories (with different relative complexities) and try to do those stories in our next iteration/sprint.

Let’s say we end up finishing 6 user stories at the end of this iteration/sprint. We add up all the story points for each user story which was completed and we say that’s our velocity.

Next iteration/sprint, we say we can roughly pick up same amount of total story points based on our velocity. And we plan our iterations/sprints this way. We find an oscillating velocity each iteration/sprint, which in theory should normalize over a period of time.

But do you see a fundamental error in this approach?

First we said, 2-story points does not mean 2 times bigger than 1-story point. Let’s say to implement a 1-point story it might take 6 hrs, while to implement a 2-point story it takes 9 hrs. Hence we assigned random numbers (Fibonacci series) to story points in the first place. But then we go and add them all up.

If you still don’t get it, let me explain with an example.

In the nth iteration/sprint, we implemented 6 stories:

• Two 1-point story
• Two 3-point stories
• One 5-point story
• One 8-point story

So our total velocity is ( 2*1 + 2*3 + 5 + 8 ) = 21 points. In 2 weeks we got 21 points done, hence our velocity is 21.

Next iteration/sprit, we’ll take:

* Twenty One 1-point stories

Take a wild guess what would happen?

Yeah I know, hence we don’t take just one iteration/sprint’s velocity, we take an average across many iterations/sprints.

But its a real big stretch to take something which was inherently not meant to be mathematical or statistical in nature and calculate velocity based on it.

If velocity anyway averages out over a period of time, then why not just count the number of stories and use them as your velocity instead of doing story-points?

Over a period of time stories will roughly be broken down to similar size stories and even if they don’t, they will average out.

Isn’t that much simpler (with about the same amount of error) than doing all the story point business?

I used this approach for few years and did certainly benefit from it. No doubt its better than effort estimation upfront. But is this the best we can do?

I know many teams who don’t do effort estimation or relative complexity estimation and moved to a flow model instead of trying to fit thing into the box.

Consider reading my blog on Estimations Considered Harmful.

A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.

At the Agile Coach Camp Goa 2010, we had a small side discussion about the difference between Use Case and User Stories. More importantly, if an Use Case contains many User stories or whether an User Story contains many Use Cases.

According to Mike Cohn, User Stories are smaller in scope compared to Use Cases.

Even Martin Fowler has the same understanding.

IMHO it does not matter. But it’s important to note that when some people refer to User Stories, they really mean the final stage of the User Story. Hence they always say, an Use Case contains many User Stories. In real world, I see User Stories have a life-cycle. They start out big & vague and gradually are thin sliced to executable User Stories. Mike Cohn referes to them as Theme > Epic > Story > Task.

I’m particularly influenced by Jeff Patton’s Work on this topic. Jeff highlights that User Stories really need to be at an User Goal level rather than an implementation level (at least when you start out). Else it would lead to big-upfront-design. Also most users won’t be able to relate to really granular stories. Highly recommend reading his blog on The Mystery of Shrinking Stories.

To understand the overall approach check out his User Story Mapping Slides.

1. Agile (as practiced today) is the new Waterfall
2. Naked Agile
3. Biggest Stinkers
4. Goodbye Simplicity; I’m Object Obsessed
5. Want to Pair Program and Concerned about Productivity?
6. Estimation Considered Harmful
7. Refactoring Legacy Projects: Scaffolding Technique
8. Single Responsibility Principle Demystified
9. Primitive Obsession
10. Cannot Evaluate a Candidate just based on their Resume

These days, its common to see teams doing the Product Backlog Management to Sprint Planning t0 Daily Scrums to Reviews to Retrospectives perfectly fine, as described in the book (or the 2 days Certified Scrum Master course). We are doing all the process stuff correctly, except that we don’t seem to be”actually” making money (minting). But somehow along the way, we seemed to have missed the point.

The problem I see is, teams are doing all the process stuff, as they are told, except that, post demo they don’t actually release the software (deploy it into production). Most teams are very happy showing the demos at the end of the sprints. They start thinking that this new process they are following is magical. Until 6 months later, their so-called “Product Owner” comes backs saying I didn’t quite expect “this” this-way and I thought “that” would be “this” and not really “that”. That is when it hits the team that what they were really doing was building inventory and basically doing a compressed-waterfall.

Until you actually release your software and see your end-users actually use it in real life, you don’t have the most important feedback. Hence you are not “done” until you really see you users use the feature you just released (and probably you are not even done after that. “Done-Done” was a cute concept, get over it). There is no better means of feedback nor is there a better risk-reduction strategy other than releasing software to production frequently (at least every week).

Remember code that is not yet deploy and just sitting in your repository is a liability. So is, all your fancy product backlogs and grandiose plans.

In the Second Edition of the eXtreme Programming Explained, Kent Beck writes:

“Software development has been steered wrong by the word ‘requirement’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence – inhibitors to embracing change. And, the word ‘requirement’ is just plain wrong.”

On his blog, Jeff Patton tries to explain why using the word requirement is plain wrong:

• When faced with challenges or in pursuit of a goal we decide on a course of action
• The software we eventually build is the compounding of a great number of decisions
• “Requirement” is a label we put on our decisions
• Decisions and requirements build on each other
• Giving requirements stops collaboration
• Asking for requirements avoids responsibility
• Requirements come from outside, not inside
• Stop using that word and start collaborating to solve problems

There are great points. In addition I feel:

Typically requirements for given business problem is derived based on some hypothesis. In today’s dynamic world, where Change is the only constant, those hypothesis can change. So instead of holding on to the by-product of the hypothesis, why not focus on the real business problem that we are trying to solve.

Requirements belongs to the solution domain. Since, there are multiple ways to solve any problem. Prematurely deciding on any one solution does not seem like a good idea. We need to spend time in the problem domain to actually come up with the closest solution.

The word requirements comes from a Target driven planning approach. Target Driven Planning has huge drawbacks that Agile methods try to avoid. Instead they focus on value driven planning.

When ever I hear about Business Analysis capturing the requirements, it reminds me of waiters in a restaurant. In most restaurant, you have a menu to select from, a waiter who will take your order (requirement) and pass it on to the chef (developers). I don’t mean to look down upon Business Analysts or Waiters.

What I’m trying to highlight is, in my experience, the BAs I’ve worked with, pretty much capture what the customer wants in form of requirements. But there is no rationale behind what is the real problem that we are trying to solve. Even if that is understand by the BA, its not communicated to everyone on the team. Do we even need some software for it? Critical questions seems to be missed out.

Also going back to the analogy, I think the analogy is flawed. In software, customers don’t get a menu. Even if they get a menu its in a language they don’t understand and to make matters worst the restaurant is serving a cuisine that the customers have no clue about. How can one possible order stuff without actually having a conversion around what kind of an appetite they have, whether they are in a hurry or not, if they like spicy food or not and so on.