Reading Simon Baker’s post on metrics made me smile. I rant about similar misuse of metrics quite a lot. A common reason that I see targets and metrics fail is because they’re aimed at a perceived circle of responsibility – for instance, developers who are measured on how few bugs they produce. This ignores the possibility that something outside of the development team might be causing the bugs – poor analysis, a difficult technical environment, lack of a decent production-like staging platform, etc.
Simon’s post calls out another common local optimisation. He says, “…the true purpose of the people doing the work, which is to improve service and quality and satisfy users.”
One of the ways in which we can satisfy users is through usability and user experience. At one of the Agile 2009 keynotes, Jared M. Spool gave a beautiful example of why this could be a bad idea. He talked about a company that had reduced a 5-stage process to 2. The users loved it. “Unfortunately, they forgot that the company was paid per page impression,” he said. The company went bankrupt shortly after putting the beautiful new website in place.
In Feature Injection, Chris Matts calls out the people with the original idea, or the people who are investing in the idea, as the core stakeholders. These are the people who need to be satisfied. Everyone else is incidental, and the vision is usually one that either makes money, saves money or protects money (stops another company spoiling your idea, or stops them from stealing your market share). Everyone else whose input is needed to make the vision a success is an incidental stakeholder. This can include the users.
Here’s an example of how focusing on the true stakeholder can help. I was talking to a friend at XtC about a user-centric story.
As a user
I want register to be emailed when the game is released
So that I can buy it as quickly as possible.
I was discussing alternative ways of implementing this story which didn’t involve email. “Who really wants the users to be notified? Who’s actually paying to notify them?”
“Marketing, I guess.”
“Why do Marketing want the user to be emailed?”
“So that they can make a big hype about the game when it’s released.”
So, rephrase this from Marketing’s point of view.
In order to make a big hype about the game when it's released
As Fred, the Marketing guy
I want users to register for an email about the release.
Now we can see that perhaps, users may not want to register for the game. We might have to entice them with something else. We also see that our goal – the big hype – could be met by other methods; with advertising, for instance, or by getting favourable reviews in magazines.
By allowing the developers to focus on the goal, we may come up with different or better solutions. We also come up with different tests. Will the user actually want to navigate through the 5 screens we make them fill in to register? Will we get the big hype we’re looking for?
I find when using the Feature Injection template that I frequently put the real name of the stakeholder on the card. This means that if we run into trouble, we can go and talk to the stakeholder about alternate ways of achieving their goal.
They’re not user stories. They’re stakeholder stories.
Liz Keogh, lunivore 
Brilliantly put Liz! This is so common and I’ve struggled with this many times myself. The real stakeholders quite often never touch the system.
Kind regards
Niclas Nilsson, factor10
Yes Liz!
Totally agree! Thinking in “stakeholders” also opens up the door to write stories that cover “technical debt”, or the need for smoothing up release processes, or learning (“As head of development, I want all programmers to know how to roll back a failed commit, so we can get rid of all these stops”).
Mused on this at [http://dearjunior.blogspot.com/2009/04/as-as-stakeholder-not-actor.html]
Totally agree too! By introducing the user story with the business value makes it understandable for any one in the organisation and like you mentioned gives the right focus!
I love the way that you are flipping the thinking on these things. Saw you speak with Dan North at Skilsmatter a few months ago & one of the biggest & best things I took away was this small & massive change in writing stories. By changing the name to Stakeholder stories you’ve done it again. I think it’s great the way that by paying attention to the language we deploy and changing it in small ways you are challenging (and chaning) the way we think and perceive in such big ways. Thanks.
Since reading your earlier posts on Feature Injection I’ve turned all our stories “upside down” – the result – during the earlier stages of projects, we can talk a language that stakeholders understand and they evaluate the usefulness of a story much sooner – plus they reduce the tendency to subconsciously design the system themselves that often happens when one starts with “I want to…” because they (stakeholder) are least best placed to decide the HOW but the WHY – that’s where they excel.
In a current project the ‘man with the money’ at our customer’s company took one look at the “In order to” clauses and instantly knew they were the start of his cost-benefit case. These things really smooth the project along.
Pingback: Interesting posts 2010-02-06 « The Art of Software Development
This reminds me one of the chapters in The Power of Full Engagement: “What’s the Good /Business/ Reason To Do This?” I ask that question in most storywriting sessions at least once.
Pingback: From Journeyman to Client | upstream agile - software
Pingback: Story Smells: The Valueless Story | Joseph Wilk
The ‘misuse of metrics’ anti-pattern is an old one, I’ve been ranting about it for years (see my blog post from 2008 http://foxonsoftware.blogspot.com/2008/05/demon-ex-machina.html or my 2009 slides I posted on slideshare here: http://www.slideshare.net/sleepyfox/software-metrics-8411184 )
I have found it illuminating to use FiveWhys to get to the root cause of who benefits from certain metrics or behaviours that come up in story definition.
Hi Liz, I was forwarded your post after I posted an article describing exactly the opposite of what you’ve proposed here. 🙂
While I accept that there are often cases where you need to build something that the user might not necessarily want or like, like a captcha in a registration process, I would argue that for everything you add and every line of code you write, you understand how that will impact the user. If there is not a positive impact, then why are you doing it? Sure, Fred the marketing guy wants to hype the game release by sending an email, but why did the user give his permission to receive it? If the email is full of Fred’s marketing wishes but gives the user no value, did Fred really get what he wants? Fred gets what he wants when the user gets what they want. If the user gets value, then Fred wins. So focus on what the user wants out of the email. Yes, Fred’s requirements are important – but he only gets what he wants when the user gets value. Understanding what that value is should be at the heart of user story creation.
Here’s the link to my article that I mentioned:
http://blog.williamgill.de/2011/08/25/scrum-user-stories-as-a-user-not-as-a-manager
Cheers,
Will.
Hi Will, I commented at the end of your post, but will write a bit more here.
For me, the user should ideally get the simplest possible thing that will allow the business to get value. That might be something spoinky and beautiful, or it might be cheap and ugly. Maybe it only *starts off* cheap and ugly. Doing more than is useful is as wasteful as doing too little. The only way to know is to get feedback – and often usability isn’t the most useful thing to get feedback *on*.
Hi Liz,
I also left a comment at the end of my other post which helps clarify – but I wanted to leave a thought on your comment above.
I totally, 100% agree that quick feedback is important, and delivering the smallest amount of user value quickly is important. However, ‘usability’, like quality in general, is not a gloss that you paint on to a solution when you’ve finished – usability, and quality, must be built in to the design from day one. This is true, I think, even when you deliver only a small portion of functionality. It’s a bit like bugs in software: what is more efficient? Painting on quality at the end by throwing hundreds of testers at code that is fundamentally poor? Or building quality into the cycle early? It’s the same with usability.
Also, ‘usability’ doesn’t always mean beautiful, animated, graphics, colours etc… it means clean, smooth user flows, optimised for the major use case and designed with the user in mind. (In fact, quite often beautiful, animated and graphics gets in the way of smooth, clean flows). The “with the user in mind” part is where the “As a User…” user story comes from…
cheers
will.
Hi Liz, I agree: the classical User Story format might end up being too simplistic, and point towards fake goals. A similar approach that I’ve used in the past was in “Writing Effective Use Cases” from Alistar Cockburn. Differently from the standard Use Case Form templates (which in general are …er… terrible) he focused on Goals, not necessarily including only the primary actor.
This might lead to scenarios where there are multiple goals, even conflicting sometimes, but where the team is facing a real problem (how can we increase the buzz without being perceived as a nuisance) that could lead to creative solutions.
Another interesting outcome is that digging into the real complexity and the real goals might lead to interesting twists at the business goal level. For example a story like: “As a traveller, I want to buy a train ticket, So that I can take a train” started to look somewhat fake, the real one was more like “As a traveller, I want to take a train, So that I can go home” while the ticket looked more like a necessary step for the railway company in order to get paid. Buying the ticket on the train wasn’t a visible option in the first case, while it stood out in the second one.
Not all user stories deserve this “multiple point of views” approach, but it’s definitely worthwhile knowing it!
Thanks.
Cheers
Alberto
Pingback: Technical/Infrastructure User Stories « Cultivating Software
Pingback: 与项目干系人沟通业务价值 | chainding
Pingback: Liz Keogh’s blog » They’re not User Stories
Pingback: Kipling on Requirements | The Agile Pirate
Pingback: Episode 13: Stories here, stories there, stories everywhere | The Agile Revolution
Hmm is anyone else having problems with the pictures on
this blog loading? I’m trying to determine if its a problem on my end or if it’s the blog.
Any responses would be greatly appreciated.
Marian, there are no pictures on this post. It’s possible some of the pictures have gone missing because I’ve moved the blog recently; please let me know which post you’re looking at and I’ll work to put them back. Just leave a comment on the respective post telling me to fix the pictures! 🙂
Pingback: Capability-based Planning and Lightweight Analysis | Liz Keogh, lunivore
Pingback: Are Tech Tasks Useful Work? | Software Development
Pingback: Agile Testing & BDD eXchange 2013 – Notes | Jose Lima
Pingback: 커피 세 잔으로 BDD하기 – CoffeeScript, Mocha, Chai | 이상한 모임
Stakeholder stories sound like they support the notion of the “growth hypothesis” from The Lean Startup, whereas user stories sound like they support “value hypotheses”. Not sure if this adds much to the conversation, but I’m finding it helpful to think about it this way.
Pingback: Communicate Business Value to Your Stakeholders – goAgile | Virksomhedskonsulent i Agil Ledelse | Rådgivning og Kurser
Pingback: Is the user story overrated? Some story patterns and formats to learn from – Michael’s lean and agile musings