agile « Thinking for a Change

Jan

A Fairytale about Lean Management

Portia Tung and I will co-present “Pinocchio: On Becoming a Lean Leader” at the SPA 2010 conference in London on May 18th 2010.

Come and play with us to sharpen your leadership skills!

Jan

Don’t estimate Business Value of User Stories

The previous blog entry said that we should find the Business Values before writing user stories. Once we find the Business Values, we derive the User Stories from them.

That just raises more questions:

What is Value?
What is Business Value?
Why more than one Business Value?
Where do we find the Business Values?
How do we derive User Stories from Business Values?

Let’s look at the first three questions and come back to the last two later.

What is Value?

The Institute of Value Management defines value as “…based on the relationship between satisfying needs and expectations and the resources required to achieve them” and “getting what you require for what you will pay“.

Jerry Weinberg (in “Quality Software Requirements volume 1“) says that “Quality is value to someone”.

Robin F. Goldsmith (in “Discovering Real Business Requirements for Software Project Success”) says that “A requirement describes some value we need to deliver to someone”.

So… if we “deliver value” we’ve satisfied a need or expectation of someone at a price they were willing to pay. We’ve provided someone with a benefit for a reasonable cost.

What is Business Value?

Wikipedia defines Business Value as “…an informal term that includes all forms of value that determine the health and well-being of the firm in the long-run” and notes that it goes beyond purely economic value.

Some theories (like “Shareholder Value“) try to reduce the different forms of value to one measurable value. I don’t think it’s as simple as that. An organisation is a complex system that’s impossible to reduce (or manage) with one measurement or goal. There will always be many (sometimes conflicting) goals, we might as well have these in the open.

Other theories like “Balanced Scorecard” try to strike a balance between 4 different views of the organisation.

Why more than one Business Value?

Because every definition of quality, benefit or value includes the term “…for someone”. We have different stakeholders with different goals and needs. They all have their definition and view of value. That raises two more questions:

How do we know who the relevant stakeholders are?
How do we find out what their goals and needs are?

Four views is better than one. But you’re likely to have more than four stakeholders for your project, so you’ll have more views.

Definining Business Value

Business Value may well be an informal term, but I like to define Business Value a bit more formally at the start of a project. That’s what we call “Business Value Modeling”:

Identify the relevant stakeholders
Identify their needs and goals
Agree on how we measure/test the achievement of the needs and goals
Select the (few) most important measurements and tests, the “Value Drivers”
Define the relationship between the Value Drivers.
Use the Value Drivers to focus and prioritise our work, from start to finish.

It’s important to define the relationship between the Value Drivers. E.g. we may have both “profit” and “customer satisfaction” Value Drivers. Which comes first? If we find a way to increase our profit at the expense of reduced customer satisfaction, would that be acceptable? There is no right answer. It depends on the company, the project and the circumstances.

Why agree on a Business Value Model at the start of the project?

Because the Business Value Model models what your business values.

The selection drivers and defining their relationship is bound to be a difficult conversation, but it’s one we want to have early on. If we don’t have this conversation from the start of the project we run the following risks:

Continuous discussion about priorities pulling the project hither and tither
Hidden priorities and values influencing decision making
Trying to “keep everyone happy” with compromises. Why not solve the real conflict and increase both profit and customer satisfaction? Because we’re afraid of conflict and because compromises require less work
Starting too many projects at the same time, trying to keep every customer happy.

How does your organisation prioritise projects or features?

Some organisations seem to value customer conflict avoidance above all else, leading to such unhealthy prioritisation schemes as “the customer who shouts loudest” or “the customer who shouted last” get to the top of the list. Sometimes a seemingly irrational prioritisation scheme hides some perfectly understandable values.

For example, in one company, the official strategy was to deliver product releases that contained a good mix of benefits for our customers all over the world. In reality, some customers (who happened to know the phone number of the CEO) always got their feature requests bumped to the top of the list. These customers all came from the same region. This had a negative effect on customer satisfaction and consequently sales bonuses of the salespeople in the other regions. Of course, sales bonuses were another powerful and hidden value driver for product prioritisation. Everybody knew this; nobody talked about this.

If we had had an in-depth Business Value Modeling conversation, we would have come to the following business value driver:

The needs of our “old” customers come before “new” customers, because their loyalty to us has allowed us to build this business

These old and loyal customers all had the CEO’s phone number, because they’d become customers long ago when the CEO did sales himself. They were all located in the same region because that’s where the company first started selling its products. Taking good care of your loyal customers is a perfectly valid business strategy, but because it was never articulated it created a dysfunctional prioritisation process.

How do you estimate the Business Value of User Stories? You don’t.

Estimating Business Value

At XP Days London I attended an Open Space session on “Estimating Business Value”. Ironically, it was hard to hear the other people in the working group because of the noise generated by the working group next to us discussing “Agile isn’t solving our customers problems because they’re not here“. Yup, we were discussing business value with not a customer in sight or any idea on how we could involve them in the discussion.

The topic of the session was

How do we estimate the Business Value of User Stories?

We didn’t get much result from the discussion. There’s no writeup on the open space wiki. I don’ t know if the organiser of the session got anything out of the session. I didn’t.

First of all, the session never defined what “Business Value” is. That’s the topic of a later blog post.

Secondly, I don’t think you can get a good answer to that question because it’s the wrong question.

Why is this the wrong question?

Because it presupposes that we first write User Stories and then estimate their value.

If we don’t know the value of the stories, we risk writing a lot of low (or zero) value stories. And many teams do. We write lots of User Stories in the hope of discovering the high value ones. We end up with a lot of stories that then have to be prioritised, valued, estimated and managed. Portia taught me a colourful description of this result: a Vomit of User Stories.

What are the consequences of a Vomit of User Stories?

We spend a lot of time on them:

user story telling meetings
user story cost estimation meetings
user story value estimation meetings (that’s the meeting where we force our product owner to put a value number on the user story)
user story planning meetings

Just to decide what gets done in the next iteration.

If we estimate and track tasks, not stories, we need to add

task breakdown meetings
task estimation meetings instead of story estimation meetings

Add to that

an iteration retrospective
a mid-iteration review
a show and tell meeting
daily standup meetings

Meanwhile, there’s “backlog grooming” going on. It’s a wonder anything gets done in an iteration!

Indeed, I’ve heard many managers and developers of companies that have started with Agile complain about the many meetings. They feel that they’re not getting much done.

So, what’s the correct question then?

How do we find the User Stories that deliver the Business Values?

That presupposes a different process: one where we first define what Business Values we intend to achieve and then generate those User Stories that contribute to the Business Values.

That should be a no-brainer, right?

We first decide what values (or benefits) we want to achieve before lauching a project or product
Then we find and improve the business processes that deliver that value
Then we find and improve the supporting business processes that make the value-delivering processes possible
When the team needs user stories, we take the highest value processes and break them down into user stories at the right level of granularity for the team’s needs. The team pulls the stories, so we only generate a minimal set of user stories.

The User Stories that implement those business processes clearly contribute to the business values, otherwise we wouldn’t even have considered them.

What’s the value of an iteration?

We keep talking about value and business value, but for our customers there’s no value delivered by iterations. They see real value when the product (and that’s not just software, despite “Working software over comprehensive documentation”!) gets released into the hands of users. Iterations (more correctly: timeboxes) are a useful project management tool, no more.

What’s the business value of a story?

I don’t think it matters much.

Why do you want to know the business value of a user story?

It’s no longer needed to eliminate zero or low value user stories, because we don’t create or consider them at all.
Another use could be to prioritise user stories by business value in a release or timebox. If we’ve already prioritised the business values and the processes that deliver them, we need to make sure the processes are implemented completely. So, I’d schedule user stories in such a way as to finish the high value processes as soon as possible and have as few processes in progress as possible. Other considerations, like dependencies, constraints, risks and real options, will weigh much more heavily when scheduling.

Why else would you want to know the business value of a user story?

I see no need to put a Business Value number on User Stories.

In the end, the customer doesn’t care about the allocation of user stories to timeboxes. They care that the selected business values are delivered in the release.

Asking the right question

Before we can find the right User Stories, we first need to ask our customers

What are the business values, the benefits, you need to achieve with this project or product? And how will you know you got them?

So, instead of inviting your customers to XP Days, why don’t you go to them and ask some questions? Asking questions is simple, but not easy.

Do you know what values your work is going to deliver? Do you know how your work delivers those values? If not, why are you doing this project? Why are you being paid?

Dec

‘Or’ considered harmful

Asking questions isn’t as easy as it seems

You’d think that asking questions is easy. Most of us have been doing it since we’re small children. Why is it that most people (me included) are so bad at it?

Nowadays, we start many of our conference sessions and training courses with an interviewing exercise. The exercise is very simple:

Participants work in triads and rotate through the three roles
- Interviewer asks questions
- Interviewee answers questions
- Observer notes what is being done and said. The observer is also the referee who checks that the other two players follow the role.
We set a topic that is known by the interviewee and not known by the interviewer. For example, the current or previous project of the interviewee. That actually makes the game easier. It’s harder to play the game if you know the interviewee or what they’re talking about.
During a short timebox (a few minutes), the interviewer asks questions. Only three types of questions are allowed:
- Open questions allow the interviewee to tell their story. Questions like “What does your company do?”, “What project are you working on?” or “What does your product do?” are good opening open questions. The best open question is “Can you give me an example?”
- Control questions let the interviewee fill in the facts of the story. Questions like “How many people work on the project?”, “How long is the project expected to run?” or “Where do you work?” allow the interviewer to get to the data behind the story.
- Confirmation questions let the interviewer check that they understood the interviewee. “If I’ve understood correctly, <restate what you heard in your own words>. Am I right?”. If you get a “Yes” answer, you can go on to the next part of the interview. If you get a “No” answer, you can ask the logical next Open question: “Can you tell me what I missed?”

It’s a fun game. You can download the instructions and a cheat sheet from the Agile Coach site. The game is based on the “Nine Boxes” technique from Solution Selling.

It’s too hard!

The feedback from the players and our observations show one thing: this is too hard! Interviewers have trouble following the rules and observers don’t have the courage to interrupt the interviewer when they don’t follow the rules.

In those few cases where we have someone who can actually ask questions in this format, the interviewees always remark how they feel that the interviewer really understood them. Usually, the interviewee gets some new insights.

It is hard, but it’s worth it.

How not to ask questions (a non-exhaustive list)

Closed questions push the interviewee in a corner where they can only answer Yes or No. It’s really hard to get useful information using only boolean answers. Typical conversations go like “Is it X? No. Is it Y? No. Is it Z? No!!!” If you like to fish, go to a lake.
Leading questions (or even better, Entrapment questions) lead the interviewee to give the answer the interviewer wants to get. “When have you stopped beating your wife?” is a classic example.
Discourses disguised as questions allow the interviewer to speech on their favourite subject. Sometimes they even add a closed question at the end. By then nobody knows what the question is about. The goal is to let the interviewer talk more than the interviewee. I don’t know why, but I associate this type of question with university professors or inhouse gurus.
Rethorical questions don’t really expect an answer, they have a point to make. “Are you going out wearing that?”. “Well… Maybe I’d better not. What do you recommend?”

My favourite most hated type of question (and one I use and hear too often) is the Pretend Open question. The typical form is like this: “Is it X or Y (and here the interviewer remembers they should ask open questions) OR…?” You can just hear the trailing dots. The question is long, unclear and weak. Advanced users will introduce many OR options, so as to maximize their airtime.

Help me get better

If you hear me ask any question that doesn’t fit the Open/Control/Confirm format, please correct me.

So, what did you think of this blog entry? Was it useful or just a reminder of something you already do or something you can’t use or….? Are you getting annoyed yet? Oops!

And it gets harder

Another observation from the game: hearing and seeing is also very hard. When we ask the observers to tell us what they heard and saw, we ask them to only answer with “I saw…” or “I heard…”. Most observers answer with “I think…” or “I feel…”.

When we teach people to interview and observe they “rediscover the lessons they learned as children but have since forgotten“. Maybe we should hire children as business analysts and consultants. For them all of this is natural.

Nov

XP Days Benelux 2009 is over

It’s been a busy November

Last week we organised XP Days Benelux and I’ve just about recovered from it. It was fun, as usual, and participants seemed generally happy with the event. You can see for yourself in the reports, participant retrospective and session feedback.

There are also a lot of things which could be better. The organisers are already busy setting up a retrospective and next year’s events.

A full report will follow later.

If you’ve written about XP Days Benelux, let us know. We gather all the reports on the conference website.

If you have any feedback or ideas for improvement, let us know. Even better, join the organising committee and realise your ideas.

Organising a conference is fun even if you’ve never done it before. There are enough experienced organisers to pair with. It does take some time and effort, so make sure that you’ll be able to invest in the conference. In return, you get the chance to take part in a non-IT Agile project.

Thinking for a Change

Categories

Blogroll

Pinocchio at SPA 2010