How to Measure Value

Agile is about delivering value, so it is important to understand the value you are delivering within an iteration or release. However, I seen many teams that focus on how many story points they deliver but not really thinking about the value of those story points.

So are there ways to measure value? The answer is, of course there is. One way would be to use the Planning Poker approach, but instead of estimating the effort for each story you can estimate the value of the story. In this case, the team doing the work would include the product owner, any sponsored users, and other users or subject matter experts. Just as you would start with estimating effort, you would pick one feature or user story and assign it an arbitrary value, such as eight points. Then you would go through and assign values to each of the remaining features or user stories relative to that one.

From here, there are a couple more things you can do to refine your value measurement. One approach would be to divide the value of a story by the story estimate. For example if you had a three story point story with a value of three, you would have a feature of 1 value point/story point. Likewise if you had a one story point story with a value of three you would get a answer of three value points/story point, which would indicate that this would be a more valuable story based on the value per points.

Another approach would be to calculate the cost of each user story. If you have a team that is pretty stable you can estimate how much it cost to perform an iteration. You should also know your velocity, so it's a simple math equation to come up with your cost per points. So for example if you had a five person team and average cost per person of $200/hour, you work that out for a two-week iteration you're looking at $80,000. if your velocity is 50 points then your cost per store is $1600 so an eight point story would cost $12,800.

So these are just a couple ways in which you can measure the value of what you're delivering. You could do something as simple as the T-shirt sizing approach, where a story may be small, medium, large, or extra-large in value. In any case you should look at someway to ensure that you are measuring the value you are delivering and not just the effort being completed.

Empathy Mapping

I ran an exercise at the beginning of a new project last week; Empathy Mapping. This is part of an overall approach of using Design Thinking along with agile development.

The idea to empathy mapping is to get to understand your users. Per the diagram below, you want to get an understanding of what your user thinks, says, feels, and does (though I have seen other examples that are slightly different than this). You would do this mapping for your main users for your product or the problem you're trying to solve.

To do this, you first want to identify the roles you are going to map. For each role, give them a name to personify it more. So don't call it Budget Approver, call her Laura. Draw out your map on a flipchart and draw a little sketch on Laura in the middle. Have the team talk a little about what Laura does, then have them start capturing these ideas on post-it notes and putting them on your flip chart. What you get is something like this:

Going through this exercise will help make some discoveries about what your users are going through. You can take this as a first step in identifying pain points; things you want to solve with your solution, but don't go into solutioning just yet. Take the observations and identify the themes that pop out. You can apply Affinity Diagraming for some structure if needed.

So now you are ready to get to insights. What does this really mean? Maybe it's time for the 5-Whys to help understand the situation. This is really the problem we're trying to solve. Now it's time to start discussing solutions.

As you get into development, don't throw out your maps. Keep them posted on the walls in your team room. As you are making decisions later in the project, they may help guide you.

Personal Design Thinking

I'm currently reading the book Design the Life You Love by Ayse Birsel. The book takes a look at Design Thinking and applying it to your own life. It is based on the success that the author has had as a product designer.

The book takes you through a four-step process; Deconstruction, Point of View, Reconstruction, and Expression. She uses examples from her own design career to help illustrate the steps of the process. 

In the Deconstruction phase, there are exercises to break your life down into some of its pieces. For example, in one exercise you start with the number of areas including family, work, friends, and hobbies and break those down into more meaning for you. It's really just a mind map that you're trying to create. 

The section on Point of View is meant to help you try to look at things differently. For example, she talks about how Steve Jobs looked at a rice cooker with a magnetic power cord and thought that would be a great idea for a laptop. The idea is taking something in one context and moving it to another context. 

Reconstruction is taking the pieces that have been identified and put them back together in a different way. 

Finally, Expression is about how you externalize this effort. There are some different ideas including vision letters and vision maps. 

This really is a workbook that you want to spend time on every day to go through the exercises. I would not recommend getting the book in an electronic format, it is much more practical to have the physical book that you can draw in as you go through the exercise. There are some exercises that involve drawing, mind mapping, etc and throughout the activities, you want to go back and review earlier work. 

I'm working through the last section, so I don't know how it will all turn out, but I have had some valuable insights. The book is laid out logically and it does get you to think. 

In closing, there is a quote from Ralph Caplan, author of By Design;

When it comes to life,
There is no such thing as design
There is only redesign

Ready Ready

I heard the term "Ready Ready" being used at work last week. I've heard of "Done Done" but this was a new one on me.

I remember the first time I heard the concept of done done. When a developer finishes coding, the story is done but not done done. There are a number of other steps that have to be completed before it is really done, that is done done. The team should come up with the definition of done at the start of a project. Typically it's things like coding is finished, unit testing was completed successfully, and the story was accepted by the author.

But how do you know when something is ready to start, when it's ready ready? Do you have a definition? I've seen where the work can get delayed when a story is brought into an iteration when it isn't ready to be started on for various reasons. In order to avoid problems with getting the work done in each iteration, the team should have a definition of when a story is ready to start.

So here are some ways to make sure your story is Ready-Ready:

1. Ensure the story and acceptance criteria are clear. The story should be in the proper format of As a I want to so that .
2. The size of the story is small enough to be completed within the iteration. If the story is to large, the team should look at breaking it up into smaller stories.
3. There is obvious user value.
4. The story is immediately actionable, meaning there aren't dependencies that aren’t ready. If your story requires some yet to be completed action from another team, you don't want to include it in your iteration until that action is complete.

Making sure your stories are ready to start before including them in an iteration plan helps ensure you don't run into problems during the iteration. One approach to this is to hold a backlog refinement meeting. This could be done near the end of the current iteration as a way to check the potential stories for the next couple iterations. This way, if a story isn't ready ready, it gives you a chance to get it ready before you get to the iteration planning meeting.

Taking this approach is a good way to ensure you are ready-ready.

Empathy and the Sponsored User

Empathy is an important attribute in Design Thinking. In order to solve our customer's problems, we really need to understand them. We need to walk in their shoes. But there's a limit to how far we can take this. We can spend hours talking to an astronaut, but we will never truly understand what it's like to walk in space.

Agile has this idea of the Product Owner, but you don't see much written in agile about empathy. One approach that can help you get past the empathy hurdle mentioned above is to find a key user (or users) to be part of your team. Some organizations call this a Sponsored User, the organization leading the project sponsors this person't participation in order to get their direct input into the product.

The sponsor user becomes one part of the multi-disciplinary team. Their input is important, but it isn't the only input. While they may understand the customer perspective, you need to balance all the project constraints, especially the time and cost it may take to implement some of the sponsored user's ideas. Don't lose sight of your minimal viable product (MVP) in trying to make the sponsored user happy.

You may also have more than one sponsored user, depending on the breadth of the solution you are trying to provide. If your current release has two or three major themes or epics, you could have a different sponsored user for each epic. Contrast this to the idea of having a single product owner responsible for the overall solution.

So when empathy isn't enough, make the user part of the team in order to keep the direction of your product moving the right way.

Henry Ford and Design Thinking

By LibertyGroup25 (Own work)

Henry Ford pioneered many of the ideas that are now commonplace in business, including ideas used in Design Thinking. He has been quoted as saying "If you ask people what they want, it would be a faster horse." This hits on the design thinking principle of divergence. You need to understand what problem you are solving before coming up with a solution. Henry Ford wasn't solving a problem around horses, he was solving a transportation problem.

I was in a design thinking workshop and we did an exercise where first we were asked to draw a door bell. Then we were given a problem in a different framing, we were asked to draw a way to know if someone was at the door. The second set of drawings were much different. A doorbell would have worked, but by reframing the question, many other solutions came out.

Another Henry Ford quote is "you can have any color, as long as it's black." On the surface, this might not sound very customer friendly, However, this response was due to the solution to another problem. When he was developing the production line for the Model T, he was challenged in the painting step. He found all paint colors took to long to dry, except black. By only offering black, he was actually fixing a bottle knock in his process...applying the theory of constraints as it were.

Next time you're working on a solution to a problem, spend a few minutes and think about the framing of the question. Can you change the question in order to expand you possible solutions?

What's Keeping me Busy

I thought I’d take the opportunity to share some of things that keep me busy when I’m not doing my day job.

Podcasts

Note to Self - I recently started listening to this one and find it very engaging. The topics are around how technology fits into our lives. I find Manoush Zomorodi entertaining and informative.

Design Matters - This one isn’t really about design as much as it’s about how people got to where they are. Debbie Millman has been doing this podcast for over 10 years and each episode is an interview with someone somehow related to design. Examples include folks like Seth Godin, Daniel Pink and people more on design like Ayse Birsel (keep reading) and Doug Powell.

Freakanomics - This has been a favorite of mine for a long time. It takes an interesting look at topics such as the economic impact of not getting enough sleep. While there is always a look at the data, the podcast is very entertaining, hosted by Stephen J. Dubner, one of the authors of the book of the same title.

Clockwise - I’ve listened to a lot of tech podcasts and given up on them because they are too long. My threshold for any podcast is less than an hour, preferably half of that. Clockwise fits the bill. The two hosts have two guests and each of the four brings up a questions but the whole podcast is time boxed to 30 minutes.

Books

Design the Life you Love by Ayse Birsel. Ayse was one of the guests on Design Matters, where I heard about her book. This is actually a workbook. It uses the principles of Design Thinking and applies them to your life, as the title might imply.

David and Goliath - I’ve had this one on my bookshelf since last Christmas and finally dug into it. I’ve enjoyed everything I’ve read from Malcolm Gladwell and though I’m not very far into it, so far so good.

Running - I am going to run the Chicago Marathon this fall as part of Team RMHC, raising money for the Ronald McDonald House Charity. My wife and I volunteer at our local Ronald McDonald house and I think this is a great charity. You can read more about that on my other blog (and even donate to the cause)

Design the Poster

Anyone that's been around Agile for a while has probably heard of the Design the Box exercise. The idea is to help the team define and understand the product vision.

I'm getting near the end of a project. We've had some challenges in terms of making the right decisions on scope. This has manifested itself in completing user stories only to have the business team say "I know that's what I asked for, but I don't think it's right." We didn't do a Design the Box at the start of the project.

However, as they start implementing their organizational change management approach (this tool is going to a large set of users), they are developing some communications tools including a web portal and a set of posters. These posters are 2x3 feet, have a logo and the tool name on the top, and more information below. They are going to be posted around the buildings where the target end users work. As I looked at this it hit me, if we had created this poster at the start of the project, we may have avoided some of the challenges we encountered.

So next time you're starting a project, think about what the poster might say.

Are You Experimenting?

I came across another interesting idea in Change By Design. It was presented as Toyota's ideas around training and had 4 principles:

• There is no substitute for direct observation
• Proposed changes should always be structured as experiments
• Workers and managers should experiment as frequently as possible 
• Managers should coach, not fix

This idea of experimenting caught my attention. So often as I'm designing a solution for a customer, they want to try to get the perfect solution first time out of the box. When they don't know what perfect is, they struggle to make decisions. I can recall one client, after 3 weeks of developing a complex interface, others looked at it and we went through another 3 weeks revising it. This was all in development, the real end users didn't have a chance to try it out. No experimentation at all, just managers trying to guess what was needed. No direct observation.

This is just one example of something I see a lot of. Not being open to experimenting. Smart organizations are figuring it out though. The push for a DevOps approach and employing Microservices is a move in the right direction. With DevOps, we can deploy something and if it doesn't work, we can have a different solution out in weeks or maybe months, not quarters or years. With microservices, we get away from the monolithic applications and have a bunch of small, independent components. If one doesn't work quite right, the whole system doesn't fail.

So how open is your organization to experimenting? Are failures discouraged or recognized as the first step towards success? Are you trying to get everything perfect or do you recognize that everything is a prototype, even if it's in production?

Divergence and Convergence

There's another idea from Tim Brown's Change by Design I thought was worth writing about. It's the idea of divergence and convergence.  Early in a design project (or any project), we want to collect lots of ideas. This is divergence...creating lots of possible choices. Linus Pauling, winner of 2 Nobel prizes, stated "To have a good idea, you must first have lots of ideas." If you're writing user stories, don't try to limit story creation. Just because a story is written doesn't mean it will be delivered but if it's never written it definitely won't be delivered.

Brown provides some ideas for generating ideas

• Have an overarching purpose. I think of Design the Box when I hear this.
• Involve the whole organization (or whole project team, sounds like agile again).
• Don't discard ideas just based on who came up with them
• Allow people room to experiment. This sounds like a spike to me. 

Now we get to convergence; making our choices. This is where we take a look at all our ideas and decide which ones to move forward with. It's grooming the backlog, prioritizing the stories, and throwing away the ones that don't fit our goal. Again, we should use our vision to help make these decisions. 

Brown points out the design is both art and science. The divergence is about being creative. The convergence is about using more analytical tools to make decisions. Also, don't think of this as a linear process...you may go back and forth between the two steps. For example, you just finished an iteration and are getting ready to plan the next one. You may have a divergent step and you synthesize the information generated in the iteration and demonstration but you need to quickly move to convergence to pick the user stories for the next iteration. 

Design Thinking and Constraints

I've been reading the book Change by Design by Tim Brown. It's part of my overall interest in design in general. I have found a number of interesting ideas in the book so far, and I'm not even half way through it. 

One concept had to do with constraints. Anyone that has worked much on projects know that constraints are a big part of it. He talks about three aspects of constraint; feasibility, desirability, and viability. 

Feasibility is looking at whether or not something can be done in the near future. 

Viability is looking at whether or not it's sustainable from a business model perspective. 

Finally, desirability of course is will it be something that people want. In design thinking you want to take into account all three of these aspects as you're working on a project.

As I think back to projects that I have had that have been either successful or not successful, I can see how all of these play into a project's success or failure. 

On an actual project, we can test for feasibility by doing something like a spike, a short test to prove out if the idea will work.

Viability may be a bit harder to show on a project. It will take other supporting input such as market research to prove the approach is a sustainable business model. This is probably best done before you go to far in the project.

I think there's a very strong tie between desirability and how agile projects work. It's that whole idea of working closely with your users to truly understand their needs. 

I've seen other ties between design thinking and the agile approach. I'll have more to say on the future blog post.