How do you write user stories for devops/dev tasks like setting up AB testing in the middle of a project

Question

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!

Answer 1

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.

Answer 2

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."