Those who have met me will be unsurprised to discover my work career started in sales. I received a lot of formal training which I am very thankful for from my previous employers. I remember the Miller Heiman strategic sales courses from Bowring Marsh McLennan as well as the gruelling 6 week sales training that the Prudential put you through out in Newport Pagnell where every day if you didn't pass the end of days tests, that was it, you were fired.
One of the key things I remember about all of those sales courses was the fundamental difference between a Feature and Benefit and why few people buy features, they mostly buy based on Benefits. This was how it was a few decades ago but more recently, Value based selling has become more and more popular, and for good reason.
Some of you might already know this whole Features vs. Benefits thing and if so skip on to the Value bit. If not lets have a description to frame these things and just provide some examples as I find this is the best way to learn new things.
A feature can be described as a fact or attribute of a product or service. It can be a capability that the product or service offers to the customer that enables them to do something.
You know when you go to the store because your washing machine just died and you are looking for a better one than you had? The new one spins at 1400 rpm and the old one could only spin at 800rpm. Or your microwave needs replacing and the new one is 1100 W and the old one was 900W. These are features. Facts about the product that you can use to decide if it fits your problem needs.
My scooter has a 50cc engine, my phone can display 10bit colour, my TV has a 100hz refresh rate. That Karate class costs $25 per lesson and that mowing service cuts lawns and does the edging. We can use all these features to compare products on a like for like basis but "What is in it for me?" My car has ABS brakes and Anti-submarine seats, I don't know what that means so how can it help me?
Benefits explain how a feature helps a customer or user, answering the "but want's in it for me?" question. Benefits are usually measured in some form of gain or loss and are most powerful when you can apply some kind of quantity to them. I typically start here when trying to discribe or understand a benefit.
Lets take those Anti-submarine seats. What good are they to me really? Is there a gain or loss for me here? Well yes there is, I get an increase in safety while driving (potentially even by a numerical amount or percentage) because the Feature of anti-submarine seats stops my pelvis from slipping forward during a collision and slipping free of the seat belt. What about that new microwave that is 1100W over the old 800W? Well my benefit with all that new found power is that I can save time by nuking my leftover Chinese dinner at least 30secs faster that I used to.
That new washing machine spins so much faster that it gets more water out of the clothes in less time so I can not only increase the volume of clothes I can wash in a day but I can also have a reduction in the amount of water still in the clothes at the end of the cycle, meaning they dry faster. That lawn mowing service gives me more time to spend with my kids on Saturday. All of these gains or reductions are Benefits that match to the Features. Its the benefits that really start to tell us where we might want to invest our time or money.
So whats this value thing then? I have compared the features and found a product or service that fits my needs and looks like it has a better offering. I have done my research and discovered what all that feature mumbo jumbo of Watts and Anti-submarine means to me in benefit terms. What more could their possibly be?
It's funny that in Agile, we use the term value all the time. We prioritise our backlogs based on most valuable stories, we pull work onto our kanban's based on next most valuable work. We try and define it and measure it and score it and work out how much value we have delivered to a customer. Why is it so hard to define and measure this thing called Customer Value.
Here is my take on Customer Value, I am not saying its the right one but its the one I use to help me evaluate a new product value proposition and workout the value in Epics and User Stories.
In my mind value comes from the idea that something is personally valuable and that a person or group of people find something valuable because of their principles, standards of behaviour, judgement on what is important in their life at that moment in time. In essence I find it valuable if it aligns to my personal values, which can change over time and which I may or may not share with a small or large number of people who have similar values. Values that customers hold change during their lifetime as life events happen to them. Sometimes these are feelings, thoughts and beliefs. Are you getting some idea as to why its so hard to measure value yet?
Lets go back to our anti-submarine seats. The feature is that they are anti-submarine seats, the benefit of that type of seat is that I increase my level of safety while driving. Why I find this valuable is because I have a young family and I right now I want to live to see my daughter get married one day so when driving I want to be the safest I can possibly be within my available budget. At this current point in my life I would buy a car with anti-sub seats over one that didn't because of my core values. 26 years ago I was driving a classic 1973 VW Beetle, nothing safe about those. My values were different back then.
Now what about that microwave. Its 1100W so the benefit is faster hot food. It costs more than the 900W microwave. My values right now are that I want to spend as much time with my family as I can. Is 30secs difference on my reheated Chinese dinner going to make me spend more on the 1100W microwave? Probably not. The benefit sort of aligns to my Value but not by enough to make me strongly sway one way or other, especially when I am trying to do thing on a budget. Oh wait, is that a new value of mine that I take into consideration? What would the 1100W microwave product need to have to make me spend more money, what additional value proposition could it supply to me. Entry to win 1 of 5 family holidays to Disneyland? Maybe.
So next time you are talking about Value, just double check that you are actually talking about value and not benefits and features. I review a lot of features, product specs and stories that claim they have recorded value but really have just restated the benefit. Focus on why you would part with your money, what is it that core value you have that the benefit has appealed to so much that this has become product you must have. Put yourself in the shoes of others and try and work out what their core values might be.
Re watch some of those commercials that show videos of people having fun, taking it easy, enjoying their family, exhibiting some form of emotion that makes you almost forget there is a can of soft drink in their hand or a wafer thin laptop on their desk. You are being sold the value not the product, you want to feel they way they feel or you already have the same values as the people you are watching but you don't have that thing they have so you copy their behaviour and buy it because they are your kind of people, you share their values. Look at your network of friends. Do you all drive similar cars, use the same phone brand, have the same broadband provider?
Try to use this sort of approach when filling out the Value Proposition section of your Lean Canvas, or when doing a Product Vision. When defining the features of your product and the benefit that it delivers think about your target customers. This will help you focus on what the core values of those customers are and if they would gain from the benefits at all. When writing User Stories don't just restate the want statement in the 'So That' section, "I want a to save my calendar appointment, so that my appointments are saved for future" No No No! What is the value to the customer of save calendar appointments. Its probably because they value being punctual and organised, so focus on those values instead.
Hopefully this has helped a few of you think about Value in a more practical and useable way, thinking this way drives almost all my Business Analysis and Product Ownership activities these days and I have seen real return on the extra effort it takes to define clearly the value the customer will receive. I hope you will try it and get the same results
I don't have complete answers to all the questions of Agile governance but I did start to do a comparison based on some resources, my observations or experiments on site with my clients. It's interesting when talking to staff on site who's existing position includes a governance responsibility, most initially think that Agile doesn't have any mechanism to allow for governance. If you have one of these talks, maybe the picture below will help a little.
A colleague of mine asked me "how do you create new story point estimates out of old estimates if the old estimates were wrong?" This is a good question for Scrum teams to consider as part of continuous improvement, how do we ensure we keep getting better at Story Point estimating? Here is one approach.
When you start your sprint your product backlog items (PBIs) have been story pointed, and sometimes during the sprint you realise that a PBI has been incorrectly story pointed. Don't be tempted to change the story points on a PBI during the sprint as that will mess up your tracking and burndown charts. If you have a PBI that is "ballooning" put some kind of visual reminder on the PBI in the sprint backlog so you can identify it later. Like a sticker of a balloon for example.
Here is the important bit.
When your sprint is over and hopefully that ballooned PBI is sitting in the Done column, its time to clear down your Sprint Backlog (SB). Just before you clear down the look at your Done PBIs. For the ones that ballooned, re-story point them to what they actually should of been so that you can learn from it. Do the same for any PBI that is over or under what it was originally story pointed at.
I usually then go a step further and suggest sticking good examples of a 3 story point PBI and a 5 story point PBI up on the wall near the Sprint Backlog to form a bit of a story point estimate library to help when using triangulation. The Product Owner & Team members can point to it with new PBIs in hand and ask"is it bigger or smaller than that one?"
This story point estimate library allows us to learn from our bad estimates and ensure that we continue to use triangulation estimating based on good foundations.
I am still a BA. I mostly work in Agile Teams or coach Agile Teams now and have found that there is a lack of Analytical thinking skills in some of the teams I work with. This is caused either by the lack of people in the team who have analysis as a core skill or worse, no one in the team with any previous experience in analysis at all, including the product owner.
When I look at the User Story and the Acceptance Criteria the "six honest serving men" jump out at me right away. Take a look at the picture below and see what I mean. Right there is the first 3 of the 6 serving men, who is this for, and thewhat do they want as well as the why. All right there in the Mike Cohn User Story format. This immediately allows me to choose the right analytical thinking tool for the job such as, stakeholder analysis or root cause analysis and so on.
Then for capturing the the details we have the when, where and how that can be exposed in the Acceptance Criteria for the user story. Answering questions such as when can payment be made? Where can the transfer occur from? These produce the tests and validations of the user story detail that is needed.
In Lean software development we have this principle of building quality in as early as possible. Surely then we need to make sure our User Stories are good enough, in a state of 'Ready' before we pull them into the sprint or onto the Kanban board. They don't need to be perfect but, just remember that rubbish in rubbish out.
The tools to do analytical thinking haven't changed, just when and how we apply them have. Everyone on an Agile team should have the basic skills of analytical thinking. That way we optimize as a whole (another lean principle) and maximize on the number of people who can help the product owner create and make ready the user stories for what we will build next.
Be excellent to each other :)
By Nick Foard
Agile Coach/CSM/Business Analyst/CSPO
I get this question a lot. What happens before I start my first sprint? I will answer that bigger question in a separate post. For the scope of this one, lets focus on the 9 questions you, as a Product Owner, should have good answers to before starting an Agile project.
The Silicon Valley Product Group created an Opportunity Assessment and its 9 questions are:
In my work I have the privilege of training people new to Agile. I get to see a lot of recurring patterns, objections, resistance and disbelief as we start people on their journey to realizing there are other ways to manage projects than the traditional waterfall approach some of us have lived with for decades.
I wanted to share one recurring discussion that seems to always come up in Agile Introduction training. It involves the concept that an Agile approach can tell you early on and at a high level the rough cost of the project, the length of the project, how many sprints. What we can't do is guarantee you exactly what you will get and when.
Most people do tend to agree in training sessions that even in waterfall upfront planning we are guessing costs and duration as we really don't know what is around the corner. When stuff happens we will slip the delivery date, increase the size of a phase, introduce more resource, throw some money at the issue.
The words from above that always cause the discussion in training are "What we can't do is guarantee you exactly what you will get and when" This is not about the internal running of the project, this is now about what the end customer is going to get. The first reaction from students is that "this just isn't good enough" and "surely the risk of project failure is higher".
This is coming from their perception of currently run projects or their historical exposure to them. In their current projects it's possible that customers are not getting what they want, and even when they do it's over budget or delivered late and so the business to IT relationship is 'strained'. What customer would ever agree to hand over money to a project where we couldn't tell them what they were going to get?
This is a normal response from students of course. Their reaction is based on what they know. I then explain to the students "Let's imagine that the people who usually give us a hard time about what we deliver, are now the people working along side you, or maybe a representative of those people that we call the Product Owner. Now they work very closely with the team, it's business and IT roles together with high levels of collaboration. And these people are no longer waiting to see what you are going to deliver to them, they are helping you understand what to build next. In fact it's their responsibility to manage the list of work items and re prioritise regularly what the team should build next".
At this point we have the discussion again. We explore the change in the expectation of the Customer. We discuss the fact that they have never worked this way before and then need to imagine working with the customer who now makes weekly decisions on scheduling, prioritizing, complexity of the feature etc. If the person deciding what goes into the iteration is the person representing the business their expectations change. It's not a sling it over the wall scenario anymore. Now is an "everyone work together for success" scenario.
When we are running out of time, the team work with the product owner to manage the expectation of what would generate a successful outcome. When a feature is too complex and expensive the team work with the he product owner to simplify the feature but still deliver the required business benefit.
When the business work directly with IT to produce working solutions everyone's expectations change. Everyone works together to find a successful solution that is acceptable to the business because it's the business who made the decision, along side you, week in week out.
You can see the lightbulb light up for the students as they realize the implications of this approach. I always know they have understood when someone asks "so when are you training the business people too?".
I can't think of a more fun and fulfilling way of building and delivering solutions to business problems than by doing it daily alongside the people who are going to receive the business value.
Not all of us are great at drawing. There is an element of practice involved but you can give yourself a leg up by 'borrowing' shapes and drawing concepts that others already use to describe things. Instead of having to dream something up on the spot, build up a library of your favourite icons and frames to draw that represent the topic of elements being discussed. Then practice drawing your palette of shapes so they become second nature.
Here is a really useful list of resources to help learn to visual note take and also borrow some shapes and icon ideas for your own palette.
50+ Awesome Resources to Create Visual Notes, Graphic Recordings & Sketchnotes
You might think that music is a simple thing when just listening to the radio but there are some complex elements such as tempo, pitch, intervals, modes, scales and many more that work together to deliver what we hear. Over the last year I have become fascinated with music theory and at the same time frustrated at the lack of good clear instruction on the subject that could make sense to me in layman's terms. Until I discovered Howard Goodall.
Howard is a classically trained composer and presenter on TV and Radio. He has created a number of TV shows such as The Story of Music and How music works. If you are a trainer or creator of training content take a look at some of his videos on YouTube and watch how he is able to describe complex concepts simply, how he uses props, clips, sounds, visuals almost all the time to help keep things clear. This guy takes VARK to the extreme and as a result you end up learning more and enjoying the presentation. Teachers, trainers and coaches, we can learn a lot from Howard's ability to simplify and use of the familiar everyday things to understand more complex foreign concepts.
Below is a link to How Music Works - Melody - Part one for those interested in picking up some presenting tricks from someone I consider to be a master at teaching and presenting.
What have you done today to make you feel proud?
My wife is a big fan of the TV Show Miranda. Miranda runs a shop and the shop manager now and then holds up a face mask of Heather Smalls and sings out "What have you done today to make you feel proud" from the the single Proud by M People from 2000.
It got me thinking about my work over the last 10 years in New Zealand. When I update my CV or my LinkedIn profile so many of us write about the technology we have handled or been exposed to. Or we list out the frameworks we know and can implement such as UML, BPMN and Agile. I do this too and none of this makes me feel proud or gives me the warm fuzzies.
So then I decided to look at my work bottom up and work my way up from technical and functional levels that I typically deliver at and see what the business problems were that I helped solve as part of a larger team. The minute I started to do this, the story changed completely as did my view of the work I had been a part of. So here goes.
What have you done in the last 10 years in NZ that makes you feel proud?
And remember if you can't trace your work to a Business problem you should challenge it as you might be wasting your time and energy.
"The most dangerous kind of waste is the waste we do not recognize". ~Shigeo Shingo
This is a question I get asked a lot. Waterfall was never intended to be used in the way we have used it. Dr Winston Royce, the guy who created the paper from which the waterfall method was mistakenly drawn, said that Waterfall actually needed 5 additional things to reduce the risk of the approach. Some of those additional things Agile attempts to resolve, but back to the question at hand.
Waterfall works well when: