eCoaching is a new way to deliver best in class lean and agile coaching.

A way for companies to access world class agile coaches in smaller and timelier chunks.

eCoaching provides access to the same great expertise as full time onsite coaching, but uses technology instead of air travel.

• You meet with the coach via video conferencing.
• The coach trains the team via webinar tools.
• Developers pair with the coach via screen sharing software.

Teams also have the option to access coaches via discussion forums or chat rooms. Posting questions and getting responses from experts.

Sample discussion

Advantages

More than just lower cost of entry:

• Short Coaching Sessions

  Short coaching sessions and more time between sessions allow time to digest the content.

  Practicing on your own without the coach aids absorption and enables you to find topics to discuss at the next session

• Fine tune the engagement

The coaching sessions become like iterations with you and the coach fine tuning the engagement.

• Change at your pace

By scheduling sessions around your needs, you can match the rate of training to the rate you can absorb it.

You control the rate of your adoption since you don't have to squeeze every ounce of knowledge from a full time coach.

How is it delivered?

eCoaching can be combined with an onsite engagement or delivered on its own.

Meet with the coach in person then engage remotely or engage remotely from the beginning.

Schedule group sessions for training, one on one or pair coaching sessions, or video conference for live help.

The key is to tailor the coaching engagement to your needs, time and budget.

Find out more about Industrial Logic's eCoaching service.

The post eCoaching: A new kind of coaching service appeared first on Industrial Logic.

In Planning Extreme Programming, Kent Beck and Martin Fowler described a user story as "a chunk of functionality that is of value to the customer."

Where is the customer value in those stories?

Note: My argument is not that those activities are not good or important things to do (they are for this team), but that thinking of them as user stories misleads the team and its customers.

The Connextra Style of User Stories

One popular format for user stories, prominent in Mike Cohn's book User Stories Applied, is a template originally developed at Connextra years ago:

    As a [role], I want to [do something] so that [reason/benefit]

The above stories fit the template, but the roles are about the creators of the system, not its users.

Users of a system don't care about the problems of the system's creators; such stories are not Valuable to them (in the sense of the INVEST model for user stories).

Where Do Poor Stories Come From?

"Stories" addressing the creators of the system seem to have several sources:

• Useful high-level stories (aka epics) that the team has split in a technical way rather than a user-focused way. The team divided them by how (technical tasks) or who will implement them (creator roles). (Splitting stories is a good tool, but splits work best when they take a customer's point of view.)
• Cargo-cult splitting: The team may have heard that stories should be smaller than a sprint, or a week, or a day, but the team doesn't really understand why or how. So they fall back to doing what they've always done: dividing features into technical tasks.
• "Busyness accounting": Tim Ottinger notes that some teams have become focused on the desire to claim velocity "credit" for any activity. In effect, they're counting effort rather than results.
• Tools: The tools we use (mental or electronic) can push us in the direction of just calling everything a story. This sloppiness can lead to a muddled view of the project's real state.

Tasks Are (Necessary) Waste

Lean thinking distinguishes between value and waste: value is what the customer wants, and anything else is waste.

From that perspective, many of the activities teams do can be regarded as a type of waste, but we don't know how to develop software effectively without doing them.

Lean teams talk about this kind of waste as "Non-Value-Added But Necessary": work we do because we have to.

Consider this conversation:
Customer: How long will it take to add feature xyz?
Programmer: Five days, including a day to refactor the frobble, and a day to test.
Customer: Then let's skip the refactoring and testing, and call it three days.
Programmer: No, if we skip those it will end up taking us even longer.

Even in this short dialog, we can see that the customer isn't confused: they just want their feature, as soon as possible. Customers value tasks instrumentally, as required steps on the way to getting what they really want.

It's not fun to think of what we do as waste, and this is not a call to skip doing the tasks that we need to develop software effectively.

Remember the "But Necessary" part: these activities might go away in a better world, but we still have to do them in this world.

We have to do technical tasks for our projects, but let's report progress in terms of value: delivering what customers want.

Tool: Context Diagrams

One tool we use to keep our stories honest is an old one: the context diagram. It shows the system in the middle, and the users or systems it communicates with around the edges.

Real stories go from outside the system boundary to inside the system, or vice versa.

If we see a story focused only on things happening inside the system, it's a sign that this is an implementation detail, not something the user regards as a system behavior.

Tool: The Role-Action-Context Template

We also default to a different template to write the headline of a story: Role-Action-Context.

For example, the story "Buyer purchases items using credit card" tells us who is using the system—the buyer, what they're doing—purchasing items, and (optionally) in what context or approach they're doing it —using a credit card.

This template helps reduce the problem of tasks masquerading as stories, and keeps stories focused on accomplishing something for a user of the system.

So What Should We Do?

First, look suspiciously at any story whose role sounds like a person involved in development, rather than a user (human, hardware, or another system) that interacts with the software at runtime.

Second, see if any of those tasks can be framed as a functional behavior or a quality characteristic of the running system; if so, rephrase them.

Finally, recognize that your team will sometimes just have tasks. You may decide to track tasks internally, but don't treat them or track them as direct progress on the developed system.

Let's write stories that provide direct benefits to our users and customers!

 
If you want to learn to write great user stories, check out our eLearning course "Composing User Stories".
 

The post “As a Developer…” Is Not a User Story appeared first on Industrial Logic.

Sprints, standups and story points have come to symbolize Agile methods much like burgers, fries and cola symbolize fast food.

Ready for your Agile Happy Meal?

I hope not.

Like researchers of fast food, we now know that the Agile Happy Meal contains unnatural ingredients that decrease agility and cause process indigestion.

In 2007, a series of experiments led my colleagues and me to increase our agility by dropping story points and velocity calculations.

Those same experiments led us to replace fixed-length sprints with a flow-based workflow, and move from standup meetings to frequent team huddles.

Our process today looks nothing like a by-the-book, mainstream Agile method largely because we actively look for process waste and experiment to discover better ways of working.

In this blog, I'll explain why we dropped story points and velocity calculations and what you can do to work successfully without them.

My Early Days with Story Points

I started using story points on an Extreme Programming team in a San Francisco startup in 1999.

I loved how story points helped identify a team's work capacity.

That capacity, calculated as velocity (number of story points completed per timebox), helped people on teams (especially product managers, product owners or internal customers) learn to work within their means.

If the work to be done in a timebox didn't add up to the team's velocity, it was time for some critical thinking and decision making about must-haves vs. nice-to-haves.

Story points and velocity helped teams save time by identifying essential functionality and removing anything unnecessary (or "maximizing the work not done", an often-repeated mantra).

I used story points and velocity for another 8 years, both on internal projects and on client projects around the globe.

During that time, I noticed many misunderstandings and misuses of story points and velocity calculations.

At first, I interpreted these problems as a sign that we needed to do a better job of educating people.

But as the years passed, it became clear that story points and velocity calculations contain deep flaws.

Irrational Story Point Inflation

One of first big problems I noticed happened in a large, famous corporation headquartered near Tampa, Florida.

We first got to know this company in 2002, when a Director (I'll call him Jim) came out to San Francisco to experience our intensive Extreme Programming Workshop.

Jim loved what he experienced and wanted to immediately bring it back to his teams in Florida.

We went on to have a 4.5 year relationship with hundreds of people within Jim's company, including 2 of the 3 major corporate divisions.

For the first team, Jim bought a complete agile transition package, including our readiness assessment, training and coaching services.

He took our advice and designed a fantastic open-space for the 25-person team (big by agile standards at the time).

He had his entire team study and discuss Patrick Lencioni's Five Dysfunctions of a Team prior to us working with them.

When we landed in warm, sunny Tampa, we met one of the best-prepared teams we had ever encountered.

Fast forward 2 years and this team had shipped a great deal of excellent software ahead of schedule, received healthy bonuses for their work and won the parent company's prestigious process improvement award.

Executives who visited the company would routinely tour this team's open workspace and learn about their process.

We were proud of this team and completely unprepared for what was about to happen to them.

One day in 2004 Jim exhorted the team to go faster.

He used the term "sprint" even though he wasn't familiar with Scrum.

This team had an average velocity around 52 points per iteration.

Their velocity would flunctuate by a few points, but generally remained steady.

Yet just weeks after Jim asked the team to "sprint", the team's velocity jumped up into the high 80s!

I asked someone what happened.

She looked at me funny and said "These days around here if you sneeze, you get a story point."

I shook my head, amazed at how a mature agile team, a team that had been assessed, trained and coached by myself and two excellent Industrial Logic coaches, could so suddenly inflate their story point estimates to appear like they were going faster.

My confidence in story points and velocity calculations began to erode after that experience.

Yet perhaps the problem had been due to insufficient education?

Rather than abandoning story points in 2004, my colleagues and I redoubled our efforts to better educate our clients, especially management, about the misuses of story points.

Sacrificing Quality For Predictability

Technical practices like test-driven development and refactoring are often the first things to be dropped when someone is trying to "make their estimate."

We see this behavior emerge from the outset, starting in training: a team that completes all work at the end of a timebox (say, two hours) often does so by sacrificing quality.

For years, we addressed this common problem by helping students experience what it was like to deliver on commitments while also producing quality code.

We explained how great teams ultimately learned to maintain technical excellence while also sustaining a consistent velocity (the same number of story points completed per sprint).

Yet the fact is, such teams are rare and their consistency is often fleeting as their team size changes or other pressures take hold.

For too many years, I thought it was important to maintain a consistent velocity, since it was supposed to be helpful in planning and predicting when a product/system could be completed.

Yet I've seen too many teams sacrifice quality and face compounding technical debt solely to make or exceed their estimates and keep their burndown charts looking pretty.

Comparing Teams By Points

Over the years I've heard several managers at different companies ask, "Why is team X getting 24 story points done per sprint, while team Y is only getting 12 story points done? Those teams are roughly the same size, so why the discrepancy?"

Instead of treating velocity as a team-specific, capacity indicator, such managers fall into the trap of thinking of velocity as a performance measurement (as Jim Highsmith described in Velocity Is Killing Agility!).

We can educate people to not compare teams by their velocities, yet it is a real problem that so many people naturally reason that such comparisons are legitimate.

Starting around 2005, I tried to deal with this problem by having teams name their story points after favorite types of fruit.

One team woud measure velocity in oranges, another would measure it in apples, another in kiwis, etc.

Then, when management invariably tried to compare the velocities of teams, I would tell them that "You can't compare apples to oranges."

While this approach helped to point out the fruitlessness (pun intended) of comparing team velocities, it led me on a path of doing more and more work to stop people from misusing story points rather than shift to a simpler and less error-prone method.

Story Point Confusion: Are We NUTs?

Many justify the use of story points because they say that humans aren't good at estimating using actual time.

They say that story points make us better at estimating because we're estimating the size of work, rather than the time it takes to complete it.

In fact, humans aren't very good at estimating in general, regardless of what measure is used.

As I will show later, teams get better estimates when they re-estimate frequently.

Story points just further muddle the issue.

While we grow up estimating using time (e.g. "When will you be ready to go?" or "How long before you arrive home?"), the same cannot be said of story points.

To use them, we must learn:

• what they are,
• how to use them,
• the many ways to not misuse them.

A typical education in story points contains a good deal of friction.

Newbies are confused and uncomfortable estimating with story points and frequently compensate by consistently translating story points back to actual time estimates.

Well-meaning agile experts do their best to educate the uninitiated.

They explain how story points are like t-shirts sizes or Fibonacci sequences.

In 2005, one of our customers found story points to be so confusing that he renamed them NUTs (Nebulous Units of Time).

Misunderstandings and misuses of story points generally multiply over time, especially as a process scales from team to department to enterprise.

Fixing those misunderstandings and misuses costs time and energy.

Story points and velocity calculations are unnatural techniques that unnecessarily confuse teams at the beginning of their agile journey.

Busy-Ness Accounting

I visited a company the other day that had giant kanban boards filled with technical tasks in various stages of completion.

I couldn't tell from these physical boards if the teams were working on valuable user stories.

I couldn't see progress on release plans and looking at their web-based Agile planning tool didn't provide much help either.

Instead, the tool was ready to show me pretty velocity charts and report on how many hours tasks took to complete.

So many Agile shops seem to be stuck in this mode of tracking busy work.

My colleague Tim Ottinger calls it "busy-ness accounting."

Breaking down a user story into tasks is fine to understand what will be involved in completing it, but spending loads of time estimating tasks and tracking the tasks on agile planning boards/tools is a lot of wasted energy and a relic of waterfall-based planning schemes.

Being agile means moving with quick, easy grace.

That means releasing useful, quality software frequently.

It doesn't mean being busy accounting for how every hour is spent doing technical tasks.

A Simpler Way

In 2001, I remember being struck by a simple planning approach mentioned by Don Wells, an early Extreme Programmer who worked on the Chrysler Comprehensive Compensation System project (the birthplace of XP).

Don said (in this email from the Extreme Programming email list):

While I wasn't ready at the time to try Don's simple planning approach, he had whet my appetite for a simpler planning formula.

Experimenting With Alternatives

By the Spring of 2007, my colleagues and I had seen enough problems associated with story points and velocity calculations that we began experimenting with simpler solutions.

Our first experiment within Industrial Logic failed badly.

We tracked real-time hours instead of story points, but we were essentially doing the same thing with hours as we had done with story points: carefully accounting for estimated hours, completed hours and a new budget of hours available for the next fixed-length timebox.

This project lasted approximately 6 months and afterwards, more than half of the people on the project said they disliked using real-time estimates with hours.

That Summer I attended the Agile2007 conference in Washington, DC and heard David Anderson speak about his Kanban method during an open space, birds-of-a-feather session.

I loved what David had described and it inspired me to continue searching for a process that better fit my company's needs and culture.

In the Fall of 2007, we stopped using story points or hours and started working in what I called (at the time) "variable length iterations."

No longer happy to work in fixed-length timeboxes, we would simply pick a small amount of important work to do, complete that work, ship it and repeat.

In general, we didn't care if it took 1 day or 4 days to get the work done.

Using the new process, we shipped (on average) 1-2 times per week.

Our agility had increased by removing once-sacred pieces from our process.

We were now even better at delivering on the promise of the Agile Manifesto's first principle:

If we had a deadline, we would make it by either getting everything done or finding work that could be safely deferred until a later release

Our planning sessions were much shorter and we judged ourselves on whether we had shipped valuable software, not whether we had maintained a consistent velocity.

I learned that what I had called "variable-length iterations" was actually more like a flow-based workflow in lean development.

And in lean terms, I started describing story points as waste, like the empty calories in cola.

Gut Feel

In 2008, Industrial Logic was asked by a Silicon Valley startup (now owned by I.B.M.) to help one team inside their company become agile.

One of our coaches worked with that team for several weeks, teaching and coaching them in traditional agile practices, including the use of story points.

At the time, we were not yet comfortable teaching our story point-free approach to our customers.

A few months after this first project completed, the company asked if we could now help them spread agile across the whole company.

We worked out a transition plan which included having me interview the first team that had already gone through the process change.

When I walked into that team's open workspace, I saw the walls covered with posters showing burn-down charts, release plans, iteration plans and charts tracking the team's velocity over time.

I sat down with a woman who had a reputation for being the company's best product manager.

After a few minutes of talking, I pointed to some of the posters on the walls and asked how things were going with planning and estimation.

For a brief moment she looked at me funny.

Then she said that everything was just fine, that they were tracking velocity with story points and using their velocity to schedule just the right amount of work for their iterations and releases.

Something about her expression suggested that something was amiss.

"Are you sure?" I asked.

She paused for several seconds, then said, "Do you want to know the real answer?"

I said yes.

She then said "You see those posters with the velocity numbers? We made all of those up because we knew you were coming to visit us and we wanted you to say nice things about us to our management."

"Really?!?", I said, rather surprised. "So what do you actually do?"

She explained that she and her team simply used gut feel to choose the right amount of work for a 2 week iteration or 2 month release.

If they needed to adjust the plan, they did so, always keeping stakeholders informed.

She said that this gut feel approach to estimation and planning had been working just fine and that they had no need for story points or velocity calculations.

I complimented her on the simplicity of her approach and assured her that what she was doing was perfectly agile, that using story points wasn't necessary to be agile.

And then I explained how Industrial Logic had stopped using story points for our own product development a year earlier.

Periodic Release Planning

Many of us estimate in order to know when we can release software to our users and what it will roughly cost.

At the beginning of a project, most release plans and dates are a nice fantasy.

You could spend days or weeks attempting to get more accurate estimates, yet I find it is better to just make rough estimates for each user story based on 10-15 minutes of analysis and discussion per story.

To get higher value for less cost, I coach teams to do Bargain Hunting.

To get more accurate estimates, I coach teams to periodically (say, every 2 weeks) re-estimate the user stories on their release plans.

As time marches on, teams that regularly re-estimate their release plans get faster at it and provide time-based estimates that become increasingly accurate as the release date approaches.

That gives management what they needed all along: a decent way to predict the scope, schedule and cost of a release.

With this approach, there is no gaming of velocity numbers and the focus repeatedly returns to scoping discussions and what will/won't be released.

I coach teams to write user stories for their releases and estimate them using "team weeks": the amount of time it will take the whole team to complete the work.

It doesn't matter if only 2 people on a team of 10 can do the work: just provide the estimate as either .5, 1, 1.5 or 2 team weeks

If the estimate for a user story exceeds 2 team weeks, I ask the team to split the story so that it can be estimated at or below 2 team weeks.

To better manage risk, it's useful to combine evolutionary design with release planning.

Your first embryonic version of the product/system should include high value features and address your highest risks.

That release (which could take 1-3 months to produce) may be an internal milestone rather than something released to customers.

The next release will add further sophistication to the emerging software by adding functionality to existing features or producing new features.

And so it continues until you are ready to release to your customers.

All along the way, a team must make sure that the number of estimated team weeks on their release plan fits with the number of calendar weeks left for the release.

If there is a discrepancy, it's time to re-scope, re-think and re-plan the release so it fits with the team's work capacity.

I've found that this style of planning is simpler and yields better results than estimating with story points and feeling bad that you didn't hit your estimated velocity for a given sprint.

Periodic release planning helps people manage risk by repeatedly focusing on what valuable functionality can be delivered.

What's the Point of Story Points?

Story points and velocity calculations are now seen as defacto parts of Agile, legitimized by popular books, embedded in planning tools, verified in certifications and widely practiced in the industry.

Yet nearly all of the veteran agile practitioners I know haven't used story points or velocity calculations in years.

In the early days of Agile we thought there was a point to story points.

Yet we were careful to not let our ideas and practices ossify: to become set in a rigidly conventional pattern.

Today, we have simpler, less defective agile estimation and planning approaches.

Some now do what Don Wells once recommended in 2001: to work on the same number of similarly-sized stories each sprint.

Others work without sprints in a flow-based model that includes periodic release planning.

While there will never be one right way to be agile about estimation and planning, you would do well to avoid yesterday's outmoded and highly defective techniques.

Or in other words, be careful of what's inside your Agile Happy Meal.

The post Stop Using Story Points appeared first on Industrial Logic.

Faking product ideas, faking product features (see Fast, Frugal Learning with a Feature Fake), faking whatever is necessary to help us rapidly and economically learn about customer needs.

So I was extremely impressed the other day with a fake that came courtesy of my daughter Eva.   

Eva (pictured in the dalmatian costume above) has a friend who was having a birthday.   The boy's parents know that their son loves Halloween.  But his birthday happens to be in April, not October.  

Showstopper right?  

Nope.

They bought lots of candy, distributed it to 4 neighbors who kindly agreed to go along with the fun and presto, six 4-year-olds trick-or-treating in April!

In the 12 years that I've been in and around kid birthday parties, I've yet to encounter such an ingenious fake!  

What are you faking these days?  

The post Halloween in April?! appeared first on Industrial Logic.

At such times, some programmers retreat and consider alternative solutions that rely on simple, ordinary code.

Other programmers refuse to give up and push forward to find whatever uncommon or arcane parts of the API, library, language or tool will yield a solution.

After muscling it, lesser programmers are often proud of their handiwork.

"Look at how brilliant I am! While mere mortals would have given up, I found a way to write this code using sophisticated, seldom-used techniques."

A Muscled Design

Ten years ago, a colleague and I programmed Industrial Logic's services catalog.

We were using Java, XML and XSLT to transform our company's training/coaching catalog into HTML.

I had a good deal of XSLT experience from previous client work and knew that the best way to work with XSLT was to keep it simple.

I explained that to my colleague who had less experience than me.

I said "if we ever have to dig really deep into the XSLT documentation to figure out how to do something hard, chances are there is an easier way to get it done by simply producing XML that is easier to transform."

He agreed.

At the time, I was traveling a fair bit, so my colleague had some solo programming time.

When I got back from one trip, he had managed to dig very deep into the XSLT library to find a way to format dates so that they looked pretty in our catalog.

The resulting XSLT was hard to read and used some arcane XSLT techniques that were buried in the XSLT documentation.

As I studied the solution, it was abundantly clear that he could have performed the date formatting logic quite easily in Java, output that formatted date as XML and then used simple XSLT to transform it into HTML.

Such Java code would not have been hard to write and it would have resulted in simple, ordinary Java, XML and XLST.

Instead we had a complicated XSLT routine.

The post Muscling It appeared first on Industrial Logic.

Yesterday, we found the following badass query in our CompletionStatusRepository class:

We looked at the above code and said huh?

So many joins!

WTF?

Could it really be that hard to get this information?

WTF!!

No, there had to be an easier way.

My pair programmer that afternoon, Adam Sroka, and I puzzled our way into this logic and the code that calls it.

For a while, we just went in circles.

Then we got somewhere.

We sketched out some pseudo-code and agreed that it could work.

We already had good test coverage for this code, so we felt free to refactor.

We did not start by refactoring the badass query.

We began by working on the code that calls the query.

That code looked like this:

The problem with the uniqueIdsFor(...) method is that it relied heavily on the badass query in the keysOfCompletedPagesFor(...) method.

We reasoned that ViewableAlbum already knew the information that the code was working so hard to re-acquire via the query's joins.

To try out our experiment, we first test-drove a new method on the CompletionStatusRepository class:

That new method reused the existing getPageCompletionFor(...) method, which itself uses simple HQL (Hibernate Query Language) based criteria methods:

Now we were ready to try our experiment. So we went back to the uniqueIdsFor(...) method and rewrote it to use a simple loop:

That worked!

Yes, it performs a query for every page, yet we reasoned that since our albums have less than 150 pages, the performance would be fine (and if not, we could optimize later).

This refactoring positioned us to make some deeper design changes that were needed to continue developing this new feature we're working on.

It felt extremely good to kill off a badass query that reeked of Conditional Complexity. Now we've just got a simple loop, calling a simple query.

The post Replace Badass Query With Simple Loop appeared first on Industrial Logic.

It rocks.

It rocks far more than Agile.

Here's a table to illustrate some differences (sorry for not defining each term, I'll leave that as an exercise for you):

Agile	Lean Startup
Product Roadmap	Business Model Canvas
Product Vision	Product Market Fit
Release Plan	Minimal Viable Product
Sprint	Kanban
Sprint Review	Pivot or Persevere Decision
On-Site Customer	"Get Out Of The Building"
User Story	Hypothesis
Backlog	"To Learn" List
Definition of Done	Validated Learning
Red-Green-Refactor	Learn-Measure-Build
Customer Feedback	Customer Validation
Acceptance Test	Split Test
Velocity	AARRR
Mock Object	Feature Fake
Continuous Integration	Continuous Deployment
Certified Scrum Master	Customer Success Manager

I suggest that you start learning about Lean Startup right away and go buy Eric's book.

The post Agile Vs. Lean Startup appeared first on Industrial Logic.

Read the Businesswire story about this new partnership...

Industrial Logic is very pleased to announce our partnership with VersionOne. We are excited to offer our innovative Agile eLearning to a broader market to ensure the overall success of enterprise agile adoption.

This partnership will address the needs of VersionOne's enterprise customers, who find it difficult and financially impractical to properly train their development teams in Test-Driven Development, Refactoring, Composing User Stories and other critical practices with traditional classroom training methods.

VersionOne gets it! Their developers use TDD, Refactoring and other agile practices every day as part of their core development process. They instantly connected with our eLearning, loved the hands-on programming exercises and the personalized feedback from our automated critique.

We are committed to producing innovative, self-paced, on-demand learning experiences that allow organizations to scale their engineering training efforts rapidly and cost effectively.

We look forward to offering our Agile eLearning products to VersionOne's global Agile community.

The post VersionOne & Industrial Logic Partner to Deliver World-Class Agile eLearning appeared first on Industrial Logic.

Listening To The Metaphor

• Dead Code
• Duplicated Code
• Comment
• Long Method
• Large Class

Smaller Learning Batches

Testing, Testing, Testing

The post Songs: Smaller Batches in eLearning appeared first on Industrial Logic.

Laura plans to write a detailed blog about Feature Fakes, but until that happens, I can't help sharing my excitement about this technique.

Group Chat Anyone?

At the recent Startup Lessons Learned conference, Brad Smith of Intuit told a great story about how Quicken users were helping each other via their product's Live Chat feature.

After the conference, I mentioned this story to my colleague, John Tangney, who quickly responded, "Yes, I love that feature! I used it the other day and someone in the chat helped me with a tax question."

I had visions of creating a similar feature in our Agile eLearning, yet I wanted to know whether our users would be interested in such a feature before investing in it.

Within three hours, John and I had developed and deployed a fake Group Chat feature on our site, along with a report to help us measure user interest.

Our fake, which sits at the top of every eLearning page users see, looks like this:

When a user clicks "Join the group chat," they see this little survey popup:

Users can close the popup or choose to answer our survey.

Here are statistics after 100 unique users saw the fake:

More Experimentation Required

Our fake was live for 3 business days, during which 100 unique users saw it.

I did not find the data to be compelling proof that we ought to build the real group chat feature.

I do wish we had done a proper A/B test of the fake feature so that we could've learned how two, differently-worded versions of the fake would've impacted the statistics.

Since we did not do that, we may run another experiment with a different Group Chat message and write some code to ensure that people who saw our previous fake will not see the new one.

Fear of Fakes

When I first heard about Feature Fakes, I was a bit worried that if we produced too many of them, our users would eventually tire of these phantom features and be afraid to click.

So I raised my concern to Laura Klein, who said:

Lessons Learned

Feature Fakes are:

• an excellent technique from the Lean UX community (thanks to Laura Klein for introducing them!)
• an invitation to your users to try a feature
• a fast way to validate interest or non-interest in a feature
• not meant to live for very long
• not proof that the feature itself will be popular (you're only testing the fake version)

I'm delighted with the speed at which we learned from our Group Chat feature fake and I definitely see us using this fast, frugal user-research technique in the future.

I'm also looking forward to learning more about this technique from Laura herself.

The post Fast, Frugal Learning with a Feature Fake appeared first on Industrial Logic.