We're in the middle of a project and have decided to implement a proper agile methodology, especially around writing "correct" user stories and trying to avoid the "as a developer" story or tasks, always focusing on user's value/benefit first.

However, we're struggling to write stories or estimate when technical work that doesn't really deliver value to the end user needs to be implemented. Here's a couple of example:

  1. Implementing unit tests: up until now we didn't have unit tests because most of the work was prototyping but since the project is picking up speed, we need to implement these and these are tasks that aren't related to a specific user story (i.e: setting up a framework like Jest for the first time)
  2. Implementing A/B testing: we want to start implementing AB testing. Again, this doesn't deliver a direct value to our users, only to us as developers/product managers.

If we were at the beginning of the project, I'd do a sprint 0 to make sure all the architecture/devops etc... is in place but in this case, it's about improving an existing project to make it more future-proofed. These tasks would really affect more than one story so it would also be weird to just lump the time under a random story.

I've considered a spike, but given that we're doing 2 weeks sprints, such spike would take at least half the sprint (we're a very small team) and i think it defeats the purpose of a spike.

Thanks for your help!

  • Either bake the work into other stories, or write stories with the team as the value consumer or viewpoint persona. – Todd A. Jacobs May 17 at 1:36
  • @ToddA.Jacobs my issue if I bake them into other stories (especially in one of them) is that the story then become way too large and if I split it across multiple stories, then if the unit testing framework isnt implemented in time for example, it will hold back all stories which isnt great either. As for your second point, I thought it was "agains't" agile rules to do this? I thought items in the backlog were supposed to deliver values to the end-users? – Paz May 17 at 4:32
  • 1
    Nope. Just “users of the product,” which also includes the team, the organization, and anyone else who receives value from it. Most value is consumed by end users, but they are certainly not the only ones. The challenge is in properly identifying the right value consumer for any given story. – Todd A. Jacobs May 17 at 12:52

Todd already put almost exactly what I was going to say into a comment, but it's not in an answer, so here goes.

Either bake the work into other stories, or write stories with the team as the value consumer or viewpoint persona. – Todd A. Jacobs♦

You have three approaches you can take here. Any (or all) are equally valid, in my opinion.

Bake the work into other stories

You can, for example, include 'user tests written' as part of your Definition of Done. Yes, this will make stories grow larger, but that can be fixed by breaking the stories down further into smaller vertical chunks. I would argue that trying to do functionality A in one story and user Tests for A in two separate stories is splitting the work horizontally. Breaking A down into B, C, and D, and then having three separate stories for each, each containing both functionality and unit testing, would be vertical slices.

Write stories with the team as the value consumer or viewpoint persona

Repeat after me: "The developers are users". Certainly, they're not typical users, but they are still stakeholders, and users. There's nothing inherently wrong with writing a story from their perspective. However, you should avoid doing that too often. Because a Backlog full of 'As a developer, I want ...' would make me leery that what you're building actually provides value. And in that vein...

Show the value, even if it's not direct

A primary reason to do unit tests is to facilitate easy future maintenance... which is valuable to the end customer. "The foo widget functionality is volatile, so as a user I need to be able to make simple change requests to it frequently in the future without those requests taking longer than a week to implement."


Short answer: you don't. User stories are for a specific purpose and you don't have to use them for all work. A user story is specifically for telling the story of a feature from the user's point of view. Since that is not what you're doing here, just put in "Write unit tests to cover catapult physics calculations" or whatever.

Now, people promote the use of user stories for very good reason. A backlog that is predominantly full of user stories will be more customer-value focused and have less waste in it (usually). So there's good reason to use them when possible, but don't feel the need to shoe-horn them in.

Edit: I wanted to add something about A/B testing. Some is for user value. Some is strictly business. I could write a story that reads, "As a user, I want a clear idea of which features comes with which license so I buy the one that's perfect for me." and in that user story, I might A/B test two designs to see which is clearer. On the other hand, if you're A/B testing two flashy pictures to see which gets more clicks, that's not really a user story, but it may be important work to the business.

  • Thanks Daniel! The reason I'm asking this is because I've seen some pretty black & white articles where it's recommended to absolutely avoid having "non user stories" because then the work you do is not delivering value, and so you shouldn't be doing it in the first place. I like the idea of having some non-user story tasks but i'm afraid we'll slip back into old habits of having a backlog full of tasks and no user value delivered – Paz May 17 at 4:30
  • I think that's a great goal to always try to tell it from a user point of view. Maybe part of the team's working agreement could be that if you aren't using a user story for your backlog item, you have to list what the delivered value is. For example, with the unit tests, you might say that this is an area of code that is critical to the process and this testing helps prevent future bugs that would disrupt important user actions. I also added a small edit to the answer about A/B testing – Daniel May 17 at 5:01
  • I should add that I used to also think everything worth doing could be done as a user story and, in my experience, it can. However, I often found that certain things actually became less clear when I tried to force it. For example, if a DB structure leads to poor search times, I could write "As a user, I want faster search times, so I don't get frustrated with large searches." but it was clearer to everyone to just write "Refactor database - at least 80% improvement on search time" – Daniel May 17 at 5:06
  • Thanks Daniel, very clear answer! – Paz May 17 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.