Tag Archive: delighting customers


Mark Lawler in his post about story points, says he wants to “raise a glass of Champagne to toast the folks who came up with the concepts of ‘story points’.  You know that way of estimating work without actually saying anything useful or making any commitment to your business customers?”

I can certainly see how the whole idea of stories and story points can be confusing, especially to new teams and certainly to business customers.  But, I would like to offer a counterpoint and say story point estimation is a very useful, and efficient technique. 

Teams are asked to make a binding estimate, generally, at the beginning of a project, when they have the least amount of familiarity and information about a project.  Here is how Scott Adams illustrates this point through Dilbert:
 
 
Let’s look at what a story is.  A story is a bite-sized, digestible “requirement” that can be completed in a time-boxed interval.  It is stated from a perspective of a real user.  A story is just enough information written down and a promise between the product owner and the delivery team to have a future conversation about the rest.  Both the product owner and the team understand that there is some amount of uncertainty involved.  The product owner is not expected to know every detail of the story upfront, and the team doesn’t always know how they are going to produce that work.
The alternative used to be a detailed business requirements document or a product requirements document.  The PM and the business stakeholder then use these documents to obtain an estimate from the delivery team.  Or many times, engineering managers or leads arrive at these estimates, even though, they might not actually do this work themselves.  Teams are then held to this estimate, no matter what new information the team learns about themselves and about their project as it unfolds.
So how good are humans at estimating in absolute terms?  See if the following conversation sounds familiar to you:
An engineer’s significant other is preparing tacos for dinner.
Significant Other: How many tacos should I prepare for you, 3 or 4?
Propeller-head Engineer:  Well, let me see, I am a little hungry.
Significant Other: So 4?
Propeller-head Engineer:  I am not sure.  I had a smaller breakfast than usual.
Significant Other: So you are really hungry?  Make 5?
Propeller-head Engineer:  But, then I had this big lunch when I went out with my friends.
Significant Other: So then…3?
Propeller-head Engineer:  But, see I then went to the gym in the evening?
Exasperated Significant Other: So you’re hungry again?
Propeller-head engineer:  But, see my workout was really “light”.
Angry Significant Other: Then you are not that hungry?  Darn it, Propeller-head, will you just tell me how many tacos do you want to eat?
Propeller-head Engineer:  Tell me what kind of beans are you using?  Are you using sour cream, or guacamole?  How caloric is the salsa?
So when it comes to estimating and committing, we tend to over-analyze and take too much time to arrive at a precise answer.  On the other hand, we are actually good at comparing.  Back to the Significant Other and Propeller-head Engineer:
Significant Other: Damn it. Propeller-head, why do you always have to be so difficult?  Tell me, are you hungrier compare to last Friday, when we had tacos?
Propeller-head Engineer:  Yes I am.
Significant Other: You ate 3 tacos then.  How much hungrier are you compare to then?
Propeller-head Engineer:  I am little more hungrier than that, so let’s go with 4.
Bam, having a reference point helped speed things along (that or it must have been the wrath of the Significant Other)!  Estimating is relative sizing, so a team compares one story to others and arranges in generally like-sized groupings.  The story points are just a numeric values we assign to these piles.  Three considerations go into sizing a story:  effort, complexity and doubt.  So along with effort and complexity, uncertainty is built into these estimation.  What was the alternative in the past?  As other agilists have pointed out – the delivery teams were trained  in stating precise inaccuracies.  At the inception of a project, when the agile team and the business partners have the least amount of information for their projects, if we ask them to be prescient and produce accurate estimates; they will produce estimates, and precise ones, at that.  Just not accurate ones!
 
For example, I was just reminded, at a recent training, regarding the concept of accuracy and precision.  If I state that the value of Pi is 3.7909430, it is very precise, but it isn’t very accurate.  If I say 3, I am accurate, but not very precise.  When we are doing newer things, we are not always so good at them at first.  We, in the software business, to use an analogy, are more like chefs, and less like short-order cooks.  Chefs concoct new recipes, so it is hard in beginning to accurately and precisely figure out how long it will take to come up with a winning recipe.  A short order cook on the other hand, is handed a recipe and has a pretty good idea of how much time it will take to cook up the recipe.  Software engineers, if they are more familiar with their problem domain, can become more accurate as well as precise.
Picture a conversation between a PM and a delivery team:
PM: We need to produce an estimate to develop an integration with our business partner.
Delivery Team: Ok, do you have the integration specs? Do you have API Specs from the partner?
PM: No we don’t, but assume that we will communicate via FTP.
Delivery Team: And how many “functions” do you think we are going to need.
PM: Assume about 10 functions.
The delivery team talks amongst themselves.
A Dev Type: Let me look at our existing code for an hour – and I will tell you.  He returns two hours later.
Dev Type: Look, we already have done this type of work.  The existing sFTP protocol we  developed has about 15 functions, which took us about 6 weeks to develop and test,  So I think, we can turn this around in 2 weeks.
A test type:  And it will take me 2 weeks to test.
Delivery Team to the PM: We can do it in 4 weeks.
PM: Well guys, sorry to break this to you, but we need this within 3.5 weeks, otherwise, we will be off our critical path.
Two weeks later.
PM: Hi guys, the specs came in, our communication is via a web service.
A stunned Delivery Team: But, we haven’t done any web services development, and certainly not with this partner.  What’s more, the infrastructure folks alone are going to need a week to open up the firewall and communicate with our partners.
PM: I know guys, this is tough.  Oh and one other thing – since we got the specs a little later than expected, we will need you to get this done within next 3 weeks.  Sound good?  Thank you guys, you are the best team I have worked with.  I know you will come through.
 
The PM, in the above example shorten the duration, but did not take into consideration the effort involved.  This generally happens when stories are express in ideal days – effort or duration get enmeshed.  Or at least, effort gets overlooked.  in which case earth days, become just as arbitrary as story points.  Comparing one team’s estimate against another becomes just as problematic as with story points.
Extending Mark Lawler’s airlines example, if say you were giving an estimate of 30 minutes delay, both times.  But say, by two different airlines – Southwest Airlines and United Airlines, which one would you trust?  Most people would probably pick Southwest as they have a stellar on-time record.  With United, who knows?  Unit of measurement is still hours, but Southwest and United Airlines estimates aren’t comparable as United doesn’t have a comparable on-time record.
 
With story point, if our customers have another key piece of data – the team’s velocity, they can also start getting better predictability.  Even when plans change, which we know, they inevitably, do.  Let’s say for example, an agile team estimates its release backlog contains stories worth 100 story points.  After sprinting for 3 sprints, they establish their average rolling velocity to be 10 story points per sprint.  Now based on this, the product owner will know that it will take another 7 sprints to exhaust the backlog (70 remaining points).  But, let’s say if the product owner estimates her “must have” story cut line is at 60 points.  She can now see that her team can achieve this with 3 more sprints (30 story points achieved and 30 more expected).  If she thinks of adding 5 more story points of “must have” scope.  She can also predict that it will take 4 more sprints (65 total must have story points).  Or say, if she wants to de-scope 10 must have story points, she can predict that the team can deliver this in 2 more sprints (20 remaining must have points).  What’s more, she doesn’t need to go back and worry about the fact that Ralph is taking a 3-week vacation or that Sally has a series of 2-hours doctor’s appointment.
 
Credit Clark and Vizdos
 
Story points, combined with team velocity, can produce fairly accurate estimates, faster.  In order to get better at estimating, more often than not, the contributing factors are that a delivery team stays constant, understands their problem domain, establishes a rhythm, and constantly inspects and adapts.  They can get better at estimation, irrespective of whether they use points, “gummy bears”, earth or martian days!  But, estimating in story points, has an advantage of not spending a whole lot of time in arriving at precise but inaccurate estimates, and avoid the trap of confusing effort and duration when contrasted with estimating in days.
 
And one last thing, just the other day, the cable guy promised he’ll be there to repair cable service, some time between 8-12pm (not very precise) and showed up at 130pm (not very accurate, either)!

Department Store - Mall (© Aashish Vaidya)

Last month, like millions of other shoppers, we headed to a department store.  We noticed that the associates were little more cheerful than in the past.  Maybe this was new a crop of temp workers who took to their jobs with gusto or just existing employees, who were spurred on by new spirit of customer service.  Within minutes, an associate greeted us warmly and moments later another one engaged us directly.  Not content with just a friendly hello, he went on to mentioned items that were on sale, especially the wool jackets, which we noticed we were passing by.  When I mentioned that I already had a short wool jacket and a long overcoat, he looked at my wife and said “well, he can always add a third in his wardrobe, right?”  Unlike typical mall-store employee, it seemed like this guy actually knew to appeal to the real decision maker.  Well, the power of suggestion was already at work and we figured that it might actually make an appropriate gift for someone on list.

As I was trying out a jacket, a third associate came by.  “Wow, ” she said, “this really looks good on you.”   When I told her that we were looking for a jacket for someone else, someone older.  She immediately went on to recommend a more conservatively styled, but a considerably less costly jacket.  This was refreshing, she was really trying to help us come up with a gift that suitable, instead of trying to power selling.

We did like the jacket she suggested, but, the store did not have it in the size we wanted.  No problem, the associate assured us, she’ll just look one up in the system and have it shipped.  She was able to locate a jacket, and we proceeded to make payment, partially with their store issued gift certificate and the rest with a credit card.  And this where things got little more interesting with a seemingly ordinary transaction.  Her system would not accept the gift certificate as a partial payment.  No problem, the associate consulted with her teammate and figure out, she can exchange the gift certificate for a gift card.  And then she processed the payment.  Nice, it was admirable to see the associate and her teammate being resourceful and making the extra effort to complete a sale.

But, the very next day, we got an email simply stating that the order was canceled and no money was charged to the credit card and the value of the gift card was reverted back to the card.  Hmmm, hello, that’s a problem!  As the gift card was fully used, so as we generally do in this situation, we had already handed the gift card back to the store associate to recycle it.

Groan – that meant having to deal with the Customer Service department.  After the usual dreadful shuffle of getting through the labyrinthine IVR system, about 30-40mins later, we got a live rep.  This rep, though, had none of the warmth and the level of engagement that the store employees exhibited.  Instead of expressing any type of regret, he told us  that a new gift card to replace our old one should make its way to us in 7-10 days.  And if we were still interested in buying a jacket, we can pick it up at a store that was about 20-25miles away, but it was no longer on sale.  And if we wanted it shipped, there would be additional shipping charges.  None of the compelling reasons of value or convenience existed for us, so we declined his offer of having the nearby store hold the item for us.

About 10 days elapsed, when the gift card didn’t show up, another call to the customer service had to be placed.  Good 45 minutes later, a “friendly” CSR,  said she couldn’t find any record that we had talked to someone about 2 weeks back in the system.  But she would revert the value on the original gift card.  Umm, deja vu, didn’t we just go through this before!  After patiently explaining to her that we no longer have the said gift card, she asked us if we can contact the store to see if they had the card.  Uhh, does she really think the store clerks would really have that particular gift card on their hands after 2 weeks?  We leaned on her, and had her finally agree to send a replacement gift card.

I recount this experience in some what details,  as this  raises a few interesting IT related systems and management questions:

  • Why would the POS (point of sale, not the other type!) system not work with the store issued gift certificate, but work with a gift card?  Did someone put in a weird business rule that no one can fathom and the frontline sales associates are left to fend for themselves?
  • Why did the system allowed overselling an item when it showed there were plenty of units available at the time of purchase?  Was the inventory not real time?  And if so, was this a usability issue where the system should have alerted the sales associate not to make the sale and have a problem until the actual inventory count is confirmed?
  • Why wasn’t the system handling a gift card related cancellation differently?  Did it always presumed that the customers will keep their spent gift card, on which the value could be restored?  Or did a product owner did not hand a properly written acceptance criteria or acceptance tests to the software IT team?  Or that the software implementation team never bothered asking?
  • Was customer service department cluelessness, a vendor management issue (if it was an outsourced vendor)?  And why wouldn’t the company properly empower their CSRs  to actually make a sale when they are in a live, high touch customer interaction?  Many other retailers have already figured this out, their store clerks or their CSRs can ship products from their warehouses or from any stores either to a convenient store location or directly to the customer.  So this was a lost opportunity.

The net effect of this was a dissatisfied customer, who lost a lot of their time and use of gift card for days.  And it was a huge waste of effort for the frontline sales staff, which worked diligently and creatively to problem-solve and make the sale.  And for the retailer, this is still a revenue sapping transaction, as it still might generate more customer service calls (the replacement gift card is yet to arrive at the end of the promised delivery window).

As IT and software professionals, many times we are so removed from actual users of our systems that we don’t provide the type of support the frontline associates need, or we don’t ask the right questions from our business or product owners.  In this particular instance, the value chain wasn’t aligned from front to back.  The system wasn’t aligned with a single focus – make a sale with least waste and satisfy the customer.

But, lest you think this is just another rant (which it is!) on usual poor customer service of a big department store, I will close with a very interesting observation we made at the store.  While we were waiting for the transaction to complete, we saw a few store associates in an impromptu “huddle”, where one of the teammates reminded others to keep restacking clothes and tidying up all the floor space.  There was even a mention to balance the engagement with customers, while at the same time flowing around so other customers feel just as welcomed.  Nice, a wonderful example of inspect and adapt.  Now only if the frontline staff can extend this spirit to their CSR and IT departments.  And if the CSR and IT departments really learn to have their spirited frontline’s back, they will be on to something!

As Steve Jobs retires from Apple, here is a collection of quotes compiled by WSJ.

There is enough good wisdom to distill from those quotes.  But, one jumps out at me:
“The cure for Apple is not cost-cutting. The cure for Apple is to innovate its way out of its current predicament.” [Apple Confidential: The Real Story of Apple Computer Inc., May 1999]

Today, more than ever, this sentiment is not only relevant to Apple, but to companies and even to countries.

And here is a very poignant Stanford commencement address he gave in 2005.  From this speech, you can also say he is a master story teller as well.

I used Macs while I was at college.  But thereafter, I was ensconced in the PC camp, especially since I worked at Compaq and Intel for few years.

Like many, I was re-introduced to Apple when the whole iPod phenomenon launched.  And I now have the iPad2.  Though, I am not an Apple “fanboy”, there is much to admire in Steve Jobs and Apple.  When it comes to design and abstracting the complexity away from the users, there are very few products out there that can do what Apple products can do.  And that is largely Jobs’ vision – making products that just works.  Working in IT, we always talk about figuring out a way to serve our customer’s needs.  But Job’s genius is in providing product to the user that he didn’t even knew he needed.  But, once he has it, the customer wonders how he lived without it!.  That is what I suppose delighting the customer is all about.  What real innovation is all about, sci-fi, but here and now!

As Jobs leaves center stage, his real legacy will be realized in 2-3 years.  This is when we will know if Apple was one man show, or will Apple continue to thrive and innovate without Jobs.

%d bloggers like this: