|
|
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?
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.
 What is Customer Value Analysis?
Customer Value Analysis is the name we came up with to describe the process we use to derive User Stories and Acceptance Criteria from project and company goals. It’s nothing new, it contains a lot of tried and tested Business and Functional Analysis techniques. It’s incremental and iterative, so that it’s a perfect frontend process to “feed” an Agile development team. It’s pull-driven, so you can keep your team fed with high value User Stories, just-in-time, when they need it and in the form they need it.
We’ve seen many projects where the Onsite Customer or Product Owner became the bottleneck, as the development team’s velocity improved. Customer Value Analysis contains the process and techniques we’ve used to exploit and elevate the analysis bottleneck and subordinate it to development again. Now the development team can continue to improve, because the Customer can keep up.
The companies where we’ve applied Customer Value Analysis are always suprised by how much value their teams can deliver. How do they do it? They
- Identify the high value needs
- Derive the leanest possible implementation that satisfies the needs, by taking small steps and really understanding the situation
- Challenge constraints and assumptions to find breakthrough solutions
- Describe the solutions with User Stories and Acceptance Criteria
- Do this efficiently, reliably and repeatably
Come and play with us!
Portia and I deliver a series of Customer Value Analysis training sessions, organised by emergn in London. You can expect a hands-on, fun-filled and very intensive session where you can learn and experiment with all the techniques on a real project.
The next training course is on the 3rd and 4th November 2009 in London. See you there!
If you’re interested in a session in Belgium or your country or company, let me know.
Another session about Business Analysis. I recognise a lot of the tools and the presenter uses a similar approach to mine: derive required capabilities from the business value drivers.
However, like most of the other analysis sessions, there was too much talking and not enough listening or doing. There was no participant interaction, just a long, monotone discourse.
Olla let the participants see the difference between Push and Pull scheduling, first with examples from his past flipping burgers, then with a simple simulation. We had to work together to fold paper airplanes. This time I was the lucky player who got to be the bottleneck. We then told each other about similar situations in our work life. Most of the stories were about integration testing being the bottleneck.
Participants liked the pull system better: less waste, less stress, better quality.
I’ve sent Olla a complete perfection game about the session, but here are some of the highlights:
To make it perfect
- Use an example that is “pure push”, not the mixture of push and pull used at McDonalds
- Explain the advantages and drawbacks of each method
- Link push and pull to IT, to help participants see the connection
- How do we proceed if we want to install a pull system?
Tsutomo contacted me before the conference to exchange game development ideas and I met him and his Japanese friends at the Thoughtworks office. Unfortunately, I couldn’t attend the session because I wanted to take part in the two sessions described above. I only got to see the end of the game, but the game seemed to be a success: participants were really involved and they got better insights into Kanban. Tsutomo got some good feedback to improve the game. The game is published on Tsutomo’s site. I hope to see this game again, improved with player feedback.
Closing
Thursday evening’s banquet set a speed record: one dish had only just been served or the waiters asked if they could remove the plate and plunk the next dish on the table. In contrast, Jared Spool’s closing keynote, although entertaining and informative, set a length record. What with all the announcements, people were fidgeting to leave. The evening ended with a few drinks and lots of discussion of agile, lean and organisations.
I didn’t participate in Friday’s open space sessions, just said goodbye to a few people. After a breakfast meeting and a visit to the Museum of Modern Art came the long flights back to Belgium. Another Agile200x has gone. Next year’s conference will be in Nashville, Tennessee, home of Country music 🙂
 Games, games games
 We innovated with The Bottleneck Game to be able to accomodate more participants: Portia and I ran two parallel simulations with two groups. Between each round, everybody got back together to share lessons and improvements. As it was only the second time we’d run the game this way, we were a bit nervous. But the game went very smoothly. By the end our smiling participants were uncertified Theory of Constraints consultants. From now on, they’ll see bottlenecks everywhere.
One of the participants who played the role of consultant when so far to as to plot the game on his portable whiteboard so that we knew our cycle time and could see where there were hiccups in the process.
The Business Value Game was too crowded and noisy. We wanted to limit the number of players because we know that too large teams have difficulty to reach consensus. Unfortunately, the room wasn’t large enough to let extra participants sit on the sides as observer.
In this interactive workshop we got to tell stories with the help of different sets of cards. A simple, fairytale-like set of cards led us to tell a meandering story about foxes, witches, queens and treasure. A more complex set of cards with multiple meanings led to a nightmare-like, surreal story with incoherent jumps.
Telling stories allows us to add meaning and emotion to the information we’re giving. The cards add a tactile and visual element to touch on more of our learning modes, not just hearing or reading. These techniques are useful for retrospectives, training and coaching.
Another interactive session, where Jenni and Ole used a flirting metaphor to help us to connect and communicate better with our co-workers. The session was built around and eight step model:
- Radar: first you have to be aware of yourself and your environment
- Target: you have to choose who you need to connect to
- Move in: show interest in the other’s perspective and connect
- Back of a little: give the other person the room, the option, to connect with your or not
- Open up: share something personal
- Dance: have fun together
- Get real: overcome problems together
- Enjoy!
The flirting metaphor was unexpected and could have been awkward, but Jenni and Ole’s humour and the openness of the participants made it a fun session.
Thursday
There are a lot more interesting sessions on Thursday. Looking at the program the theme for the day is likely to be “Business Analysis” because I think it’s essential and we’re still not getting it right. Unfortunately, that means I’ll have to miss Tsutomo Yasui’s Kanban Game.
More about today’s sessions later.
|
|
