“As a Developer…” Is Not a User Story

Posted November 26, 2012 by Bill Wake

Look at these "user stories" I recently encountered:

As a developer, I want to refactor the BarSplat module so that it has less duplication
As a developer, I want to configure Jenkins so that we have continuous integration
As a product owner, I want to have the stories estimated so that we can make a good plan
As a tester, I want the test cases defined so I can test the system

In Planning Extreme Programming, Kent Beck and Martin Fowler described a user story as "a chunk of functionality that is of value to the customer."

Where is the customer value in those stories?

Note: My argument is not that those activities are not good or important things to do (they are for this team), but that thinking of them as user stories misleads the team and its customers.

Writing something in the form of a user story when it's not about users of the system misses the point.

The Connextra Style of User Stories

One popular format for user stories, prominent in Mike Cohn's book User Stories Applied, is a template originally developed at Connextra years ago:

    As a [role], I want to [do something] so that [reason/benefit]

The above stories fit the template, but the roles are about the creators of the system, not its users.

Users of a system don't care about the problems of the system's creators; such stories are not Valuable to them (in the sense of the INVEST model for user stories).

Where Do Poor Stories Come From?

"Stories" addressing the creators of the system seem to have several sources:

  • Useful high-level stories (aka epics) that the team has split in a technical way rather than a user-focused way. The team divided them by how (technical tasks) or who will implement them (creator roles). (Splitting stories is a good tool, but splits work best when they take a customer's point of view.)
  • Cargo-cult splitting: The team may have heard that stories should be smaller than a sprint, or a week, or a day, but the team doesn't really understand why or how. So they fall back to doing what they've always done: dividing features into technical tasks.
  • "Busyness accounting": Tim Ottinger notes that some teams have become focused on the desire to claim velocity "credit" for any activity. In effect, they're counting effort rather than results.
  • Tools: The tools we use (mental or electronic) can push us in the direction of just calling everything a story. This sloppiness can lead to a muddled view of the project's real state.

Tasks Are (Necessary) Waste

Lean thinking distinguishes between value and waste: value is what the customer wants, and anything else is waste.

From that perspective, many of the activities teams do can be regarded as a type of waste, but we don't know how to develop software effectively without doing them.

Lean teams talk about this kind of waste as "Non-Value-Added But Necessary": work we do because we have to.

Consider this conversation:
Customer: How long will it take to add feature xyz?
Programmer: Five days, including a day to refactor the frobble, and a day to test.
Customer: Then let's skip the refactoring and testing, and call it three days.
Programmer: No, if we skip those it will end up taking us even longer.

Even in this short dialog, we can see that the customer isn't confused: they just want their feature, as soon as possible. Customers value tasks instrumentally, as required steps on the way to getting what they really want.

It's not fun to think of what we do as waste, and this is not a call to skip doing the tasks that we need to develop software effectively.

Remember the "But Necessary" part: these activities might go away in a better world, but we still have to do them in this world.

We have to do technical tasks for our projects, but let's report progress in terms of value: delivering what customers want.

Tool: Context Diagrams

One tool we use to keep our stories honest is an old one: the context diagram. It shows the system in the middle, and the users or systems it communicates with around the edges.

Context Diagram

The goal of a system is to affect things outside the system.

Real stories go from outside the system boundary to inside the system, or vice versa.

If we see a story focused only on things happening inside the system, it's a sign that this is an implementation detail, not something the user regards as a system behavior.

Tool: The Role-Action-Context Template

We also default to a different template to write the headline of a story: Role-Action-Context.

Role Something or someone that sends a stimulus into the system boundary
Action How the role triggers the stimulus; usually verb+object
Context Optional: where or when the action applies

For example, the story "Buyer purchases items using credit card" tells us who is using the system—the buyer, what they're doing—purchasing items, and (optionally) in what context or approach they're doing it —using a credit card.

This template helps reduce the problem of tasks masquerading as stories, and keeps stories focused on accomplishing something for a user of the system.

So What Should We Do?

First, look suspiciously at any story whose role sounds like a person involved in development, rather than a user (human, hardware, or another system) that interacts with the software at runtime.

Second, see if any of those tasks can be framed as a functional behavior or a quality characteristic of the running system; if so, rephrase them.

Tasks are for the development team.
Focus on stories as progress, not tasks.

Finally, recognize that your team will sometimes just have tasks. You may decide to track tasks internally, but don't treat them or track them as direct progress on the developed system.

Let's write stories that provide direct benefits to our users and customers!

Composing User Stories
 
If you want to learn to write great user stories, check out our eLearning course "Composing User Stories".
 

32 Responses to ““As a Developer…” Is Not a User Story”

  1. Rajesh A says:

    Interesting article. We do create and execute the stories of this sort (As a developer…). I guess the article is talking about Ideal Agile World. In the current world, how do we address the bugfixing, refactoring (code from previous sprint needs refactoring) ? how about the stories for “performance testing” ? I know, we can manage by pushging this tech work during release testing phase, but its going to increase the release phase duration and product owner may not wait for 6 to 8 weeks after completing the development of all stories. I would like to see how this is managed in rest of the Agile world.

    • Bill Wake says:

      (Sorry if I’m replying twice; something seems to have been lost).

      Stories about bug fixing I treat as a (regrettable) iteration on the original story. I try to do refactoring along the way, or at least tied to the next related story that comes along, but if I had to do it standalone I’d call it a technical task (possibly tied to some sort of maintainability requirement, but the deeper issue is probably a process gap). Performance testing isn’t a problem – it’s presumably a task that’s part of delivering some performance requirement, typically attached to a story.

      I don’t object to the tasks we need, but I want them framed as supporting some goal of a user/customer of the system, not the development team.

      I definitely don’t try to defer any of this sort of work to some release phase; I want “pay as you go”.

    • Ram says:

      Rajesh, just curious, why should the PO wait for “6 to 8 weeks”?

    • Tim Ottinger says:

      In the rest of the agile world I’m familiar with, things are done continuously instead of being batched for later. It turns out that batching work (in hopes of getting some kind of economy of scale) tends to pessimize the performance of the system as a whole.

      Instead, we want to test continuously, refactor continuously, etc.

      Often people struggle with continually testing and refactoring, for fear it will slow them down and reduce their reported velocity. The funny thing is that’s what it is for. Your velocity should be the rate at which you do fully tested, clean, quality work.

      That said, there will be situations where some (perhaps inappropriate) shortcuts are taken to capture some late-breaking opportunity. When that happens, the refactoring isn’t a task, it just naturally lowers the velocity of planned work for the next few sprints.

      At IL, we don’t bother with story points and velocity and planning meetings any more because we’ve pretty much internalized it after many years of agile practice. But if we didn’t test, refactor, integrate, and release continuously we would have to go back to a more formal framework to get the work back under control.

      Does that help?

  2. Philipp says:

    How would you formulate user stories for a team which creates an automated test roboter, or supports the developers in writing better unit and integration tests? Do user stories make sense for such “infrastructure” work or should we think in terms of tasks, which are part of a user story (our testers are working side by side with the developers)?

    • Bill Wake says:

      If you’re writing a testing tool, I have no objections if some of your stories are about testers or developers. But if you’re talking about testing a particular feature, then I’d rather think of this as a task/activity supporting that feature. (I realize on big enough projects lines will be fuzzier, and it will take extra work to keep the ultimate users’ needs visible down multiple layers.)

  3. Sven Peetz says:

    I often struggled with those situations. I do agree that often developers are not customers (sometimes they are as I will describe later) – but I don’t think that we have to doom their Userstories from the backlog. I mean we can, if it helps us improving our process – but as long as those stories do not disturb us, we don’t have to think about that. And there are reason for that:

    First of all it wouldn’t be very agile trying to define fundamental rules. Remember: Individuals and interactions over processes and tools. So if you are happy with stories from developers and if they help you to improve quality of your software – don’t change it. Never change something that is working. Of course – if it is not, check out if the approach described in this blog is good for you.

    But then there is another aspect: you could imagine the company the development team is working at – as the customer of the development team. Especially if the software is running InHouse (e.g. services as SaaS or Websites). Thinking about that developers – as representatives of their own company – are customers. So if they do have stories that fulfilll the needs of their own company, i.e. by reducing cost for feature development or by increasing quality of the code base (which also reduces cost), they may have valid user stories.

    But please – if you are a developer – don’t start using this to spam the backlog with technical stories just because it is possible 😉

  4. Bob says:

    Great post! Our team is struggling with becoming “Agile” and we have fallen victim to the same phenomenon you describe above. My question: Does the team story-point out the “wasteful, but necessary” tasks and assign these to Sprints? If these type of system development tasks take a developer away from completing “real” user stories for the customer, these tasks will affect the team’s velocity, so they should be captured (somehow) and be assigned to a sprint along with the actual user stories for the end users, right?

    • Bill Wake says:

      I’d like “wasteful-but-necessary” tasks to be part of stories where possible, so any estimate of the story includes them. (Not that I’m so big on estimates:) Where they can’t, you’re right that they will take time from the “real” development, so we have to consider that when we talk about what we’ll get done. I want to measure progress in terms of features/capabilities/performance etc. that the user cares about, not in terms of how busy we are.

  5. Great post. I think the key here is that velocity is an indication of direct value delivery. Introducing technical stories that contribute to velocity skews the figure that should be a measure of value delivery. As you point out, it eventually turns velocity into an effort measurement rather than a value. If you want the velocity to be a measure of effort, fair enough, but it kind of misses the point of scrum I feel.

    The desire to have velocity as a measurement of effort could be a symptom of velocity being misunderstood by management. What I mean by this is that often teams are encouraged to increase velocity without a true understanding of what velocity means. In fact I think even the terms velocity and sprint are misleading and give the impression of constant flat out effort, when in fact they are supposed to lead to a sustainable rate of value delivery. Some business cultures probably push teams into accounting for purely technical tasks in a way that distorts the productivity of a team. Even as I write “productivity” I’m thinking “that could be misinterpreted!” ….. oh the joys of semantics!

  6. Charles Bradley, Scrum Coach says:

    Bill, excellent article. I also sometimes see people creating “user stories” for technical debt items — calling them “technical stories” or some such thing. Working on stuff that is purely technical debt is controversial in and of itself.

    I cover similar topics to your article in Traps 1,2, and 8 in my article on User Story Traps: http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/

    I’m not trying to pimp my article, just adding what I believe to be a reference to a very related article that wholly supports yours as well.

    Charles Bradley

  7. Programmer says:

    More realistic scenario:

    Programmer: We can shave off one day by not refactoring and add 1 day every time we touch this code.

    Customer: ok

  8. […] 在博文《像“作为开发者……”这样的表达并非用户故事》中,Bill Wake谈到了他所遇到的对客户没什么价值的用户故事。作为例子,他提到了“作为开发者,我想配置Jenkins,以便进行持续集成”这个用户故事。Bill解释了为什么我们不应将其称作用户故事: […]

  9. Matt Alexander says:

    You mention a bunch of examples of what not to do, with no examples of how they could be done better.

  10. […] “As a Developer is not a Story” – Bill Wake “Technical Stories: We don’t need ‘em” – Ron Jeffries “Technical User Stories” Ariel Valentin […]

  11. Scrum Master says:

    The article has a good point. What are we to do for work items as such (As a Developer, …)?

    Say I want my one of my developers to research the usage of automated testing tools and create a guide/tutorial for everyone. Now this is a task for the project. If we are to encapsulate each task in a user story, how are we to construct the user story? Should this just be a spike task under the user story? or are we allowed to have tasks that are independent from user stories?

    Any suggestion will be appreciated.

    Thank you …

  12. Chris Redfern says:

    Interesting – But can you not consider a developer as a user? A developer is just someone who uses the system in a different way. For example a developer uses the system at the class or api level to build functionality. So why can’t a developer have a story to say As a developer I want less duplication of code so that I can improve the efficiency of development. Component builders like Dev Express, Telerik etc.. will treat me as a user and might have stories on how I use and interact with their components. Just a thought.

    • Agile Bob says:

      Because we want our developers thinking from a user standpoint. We want everyone thinking from a user standpoint. So you would say “As Joe user, I need less duplication of code so that the system runs efficiently for me”. The problem comes when we start thinking the developer, system or tester is needing something from the system when in actuality everything they should be doing is in the benefit of the user of the system.

  13. Rajab Natshah says:

    They are Only .. [Jokes] .. We can not use that for Real

    For Example.
    Once upon a time .. an Agile Story : [As a Software Developer I need to have a clear wireframe and fast Development Machine, Internet access, and , add to that a good Project Manager, and a quite working area. So that I will be able to study/analyse all requirements then structure to implement the system on time.] http://natshah.com/blog/once-upon-time-agile-story-software-developer-i-need

  14. […] funcionais, desenvolvedores escondendo necessidades técnicas dentro de histórias de clientes ou tentando distorcer necessidades técnicas ou de arquitetura dentro de histórias no estilo de usuário, o que acaba […]

  15. Carlton Nettleton says:

    Thank you for pointing out the obvious and hopefully all of us can work together to eliminate that awful Connextra template.

  16. laserpez says:

    Our product is quite big, so responsabilities have been distribuited to several teams. Our agile team’s boundaries are “inside” the system and it only receives stimulus by and sends “reaction” to API/services and so on. Are “user stories” still an adequate paradigm? how would you fit the “user stories” concept in this context?

  17. Lezka Rodríguez says:

    I’d like to go deeper in one of your examples. The user story “Buyer purchases items using credit card”. This may require 6 weeks of technical work which doesn’t add any value to the customer. I have a lot of stories like this one, which are very simple and short from the point of view of the customer, but that require a looot of technical work. Let’s put a stupid example for argument’s sake: “as a passenger, I want this plane to fly so that I can get to places”. The amount of work that the end user doesn’t care about from this point on is enormous. Obviously the team will have to do a lot of work before the plane flies but the customer will just be waiting and getting nothing. How would you go about this?

  18. TheHackerCIO says:

    I agree 100%. As “TheHackerCIO,” I just blogged about “Userless User Stories,” and linked to you here. I’m sick of Agile that isn’t. And pretense of every sort.

  19. code_monkey_steve says:

    value is what the customer wants, and anything else is waste.

    Does the customer want security? Reliability? Scalability? Do they care about data loss? Performance and hosting cost? Would they mind if Chinese hackers got, say, the social security numbers of all their users? They probably don’t care enough to pay for the periodic upgrades needed to keep the tech stack up-to-date, but they might care when they have to pay for a major rewrite because the stack is too old to be supported. They probably do care about uptime, but not about monitoring, alerting, redundancy, or backups.

    And what about other users within the company? The customer doesn’t care about Sales, Marketing or Customer Service, but these groups also need software support too. The customer doesn’t care if management has access to the analytics or metrics that they need to make long-term plans. They don’t care how long it takes CS to find and fix a problem (until it’s their problem).

    Do customers care about the future beyond the next fiscal quarter? If they don’t, does that mean we shouldn’t either?

  20. […] have read in some blogs that as-a-developer-is-not-a-user-story, but I have also read that scrum does not mandate these. There are few blogs where they have shared […]

Leave a Reply