I will measure this by



As a [role], I want [requirement] So that [reason], this particular arrangement of words will be familiar to any agile team. Our board is littered with cards in this format. We tend to then have acceptance criteria in the BDD style of given when then. We sometimes differentiate and have Epics for the higher level stories but it's all very familiar.

In the last few companies I've worked we've been increasingly talking about the "the measure of success", initially this was a notion and merely stated vaguely, this should improve conversion rates. Or improve the customer experience. Or everyone's favourite improve revenue. But this was the so that the reason for the story. In some cases we would have 2 so that's. The first was for the websites visitor So that i can buy music and then we'd have a second so that the company can increase its revenue. Thus linking it back to the businesses driver. I liked this small addition, because it helped us keep sight of the underlying business value that we were trying to deliver.

Build measure learn

One book that had heavily influenced my thinking of late has been The Lean Startup by Eric Ries the build measure learn cycle just makes a lot of sense.

I think there's s disconnect between the user stories we write, features we build and what we measure. In the lean startup they talk about validating features.A story has to go live to be validated but we don't have this on our board. Your definition of done is in production, feature delivered, but does that go far enough?

A new feature isn't an instant hit, we provide an API when we deploy a new endpoint it takes time for partners to integrate with it. Simple things like counters can throw some much needed light and give us a good indication of how many partners are using the new endpoint as our measure of success.

I will measure this by

The important thing about measuring success is that you need generally to measure an improvement so if you aren't measuring this thing in the first place you need to get some metrics in as a basis for comparison. It also starts you thinking about what are they key metrics for your company and what are the key metrics for your team and how do they relate to the company KPIs then going forward how does a story feedback into those metrics?

Therefore I'd like to propose an addition to the user story format, namely I will measure this by. This encourages us to ask how are we going to know whether we've truly delivered the business value, which the so that implies, if it's revenue then put a counter on for revenue from PayPal in the below example. You will then be able to confidentally say you've added business value. The card mentions comparing this against overall revenue and we're concerned with overall revenue increasing so it's entirely possible that PayPal won't increase overall revenue but just take away from the other credit card method. But we should see this because we define it in out I will measure this by.

As a <role>
I want <requirement>
So that <value>
And I will measure this by <measure of success>

Thanks and please try writing a story in this format and see how it goes.


What the Customer Cares about



Do you know what your customers care about? Recently I've been conducting short 30 minute interviews with various internal customers to try and learn a bit more about what they care about, what they worry about, their aspirations for the future and frustrations with the present. It's been quite enlightening and has yielded both great ideas worth persuing and humbling truths worth hearing.

Strangely in software development we seem to be insulated from our customers. Our project might be about "boosting revenue" or "improving efficiency" but that's often all we know. We'll have received this mission from a product owner who might be a proxy for the real departmental customer, if we're really lucky we'll have a real person from the actual department we're doing a piece of work for.

So let me ask a question, how much do you know about your customers? What does their team care about, who are their customers and what teams do they most often interact with. Book a quick meeting in with them, for an informal chat, I simply sent an informat email saying that I'd like to learn more about their team and would they mind if I interviewed them briefly. I attached the questions I was likely to ask (see below) and if they were up for it I'd book a meeting.

Here's my rough format, I'll send an email entitled:

A quick interview to help YOUR TEAM understand a little more about CUSTOMERS TEAM eg Sales / Marketing.

I'll attach the following questions to give them a heads-up and time to ponder some anwers.

So tell me about CUSTOMERS TEAM.

A nice opener, everyone sees themselves in a unique light. A sales teams might not consider themselves about revenue but about helping their clients deliver fantastic service using your product.

What are the components of CUSTOMERS TEAM at YOUR COMPANY, sub-teams, areas.

Do you know how your customers team is organised? Are they split by country or function. For example if it's marketing is there an SEO team and a Social Media team? Does copyrighting come under SEO or are they something different. Do they have teams around your companies different brands? Is the brand team under marketing or are they separate again?

Who are your customers / stakeholders

Who are your customers, customers? It is always good to see who your customer is trying to keep happy. Do copyrighting interact with legal a lot or is the SEO team the more important stakeholder in new articles written, the more you can understand your customers predicament the more you can write code that keeps their customers happy and hence your customers happy.

What teams do you often interact with, who do you depend on?

Are customer services always working with the web support team over customers having forgotten their password, maybe it's about time you put a 'forgot my password' button on the page. Wouldn't that make everyone's lifes easier.

What are the key measurements you worry about.

Is it revenue for sales? Prehaps churn rate or ARPU for marketing. Operations are likely to care about uptime, but what about Customer Services? Is it number of open queries or the average time to a query being resolved?

What are you measured by, and who measures you.

For sales you can imagine it being revenue related and probably by the CFO or CEO, but prehaps this assumption is wrong. If customer services are measured by the length a customer problem takes to solve and there's a very common problem that's very time consuming to fix, a bit of work from a development team can have a massive effect on their KPI's.

Where do you want to be in 6 months.

Are Customer Services hoping to move off some internal tool and onto some externally hosted CRM platform. What are they hoping this will give them, is there anything you can do to help? Or anything that might go wrong that they're unaware of.

If YOUR TEAM could do one thing for you what would it be.

You're not promising anything but it gives you a really good idea of your customers priorities and what they perceive as the big issues. I've been shocked to find them say it's not the project we're about to start. Apparently that was someone higher ups idea. All they want is a small feature and that'll be more than enough to help them achieve their goals. I've heard feature suggestions that are simply brilliant and not even that hard to implement and walked out thinking why didn't we think of that or why don't we have that feature we must have a 'forgot my password' link surely customers don't have to fill out a contact us form.

If Technology could do one thing for you what would it be.

Same as above but for your department. This is always a good one because it puts what they'd love from you in context with other bits of your department. "What we'd love is if we could let our Phones and Tablets on the internal network so we can test that our microsites look good on mobile devices before we go live". Ok I can talk to the network guys I'm sure they can sort that out in 10 seconds all our team do that for application feature testing anyway I can't see why you can't have the same access. It's amazing what silly little things you didn't think of can be such a big issue to other departments. I've learned we really take the privelege of being able to for example 'install chrome'  for granted as developers.

What are you excited about,.

It might be that new CRM system they've been after for months, they might be about to launch their first social media campaign, is there anything you can do to help them, or do you know another team that can. It's all about empathy and letting that inform all those millions of tiny decisions we make every day as we implement a feature or fix a bug.

It seems tragic that in a world where software is everything and building the wrong software is an expensive endevour we do so little to try and empathise with our customers. I think it was Fred George who pointed out that it is the large financial institutions that are quite used to getting programmers and traders working side by side, strangely in most modern 'agile' shops we have layers of people between 'customers' and 'developers'.

So I implore you, go out and interview your customers and get to know what they care about, and don't forget to share your interview notes with the rest of your team and even department it can only help you in producing software that helps achieve what the customer cares about.

What_the_customer_cares_about.pdf (40.84 kb)


Search

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014