How to write User Stories for technical implementation details?

Question

I'm trying to work in a more organised way and started adopting user stories.

I think I have misunderstanding of how should I use user stories for technical stuff.

Let's say I'm coding an app that gives me the ranking of my site for a certain Keyword in Google.

The user story goes like that:

As an Internet Marketer
I want to find out where my website ranks for a keyword
So I'll know whether my SEO efforts work

Now this is pretty straight forward and user centric... However, what happens if I need to introduce Proxies into the loop.

On one hand, Proxies are technical implementation detail on the other hand, proxies is part of the Internet Marketer's domain.

How should I craft such story?

As an Internet Marketer
I want to use Proxies when searching in Google
So we'll be able to check a lot of keywords without Google blocking us

The above scenario doesn't sound right for me... Maybe I can rewrite it to be something like:

As an Internet Marketer
I want to be able to check a lot of Keywords at a time
So it'll save me time

This sounds more right, however what acceptance criteria can I give it? try scraping google 100 times in a min? Isn't it waste of time?

Here's another scenario. How should I craft a user story when the feature I want to implement is that a proxy can be used once in 30 seconds? I don't have any idea of how to approach this problem from a user centric perspective...

Another thing I thought of doing is to present another Role. Instead of being centered around Internet Marketer, I can say we have a role called Google Scraper. I can say that Internet Marketer is in relation with Google Scraper.

Now I can write a user story like:

As Google Scraper
I want to change proxies every Search
So Google won't ban me

What would you say about approaching technical implementation details like above? It can also help breaking the system down into modules...

Answer 1

User Stories should not include technical details. During Sprint Planing technical details should be added as Delivery Team tasks nested below the User Story. These tasks should be created through discussion by the delivery team. You should not attempt to document every implementation detail under the sun as you will reach a point of diminishing return. Aim for 60-75 percent coverage on implementation details (tasks) for each user story as the details may change as coding begins. Any additional details developer discover during coding can be shared and documented briefly during the daily stand-up. should The User Story can be simple and non-technical while the Delivery / Development Team will flesh out story details as nested Tasks. These Task should be visible to Developers through their Integrated Development Environment (IDE). As Developers complete tasks they can associate their checked in code with the task in your work item tracking tool (Jira, Team Foundation Server, On-Time)

Answer 2

You don't write technical stories. User stories should meet the INVEST criteria.

Proxies do sound like an implementation detail and should be avoided. You should not be mentioning proxy servers in your story. Even if they are part of the domain, there are potentially other ways to achieve the same effect.

Instead of writing "I want to use a Proxy, so that I don't get blocked", you should write, "I want to disguise my identity, so that I don't get blocked". If I was your customer, I wouldn't know why you wanted a proxy? Is it a forward, open or reverse proxy? There are loads of uses for a proxy server. You should pick the feature that you want to exploit.

However, you shouldn't get too hung up on perfect stories. The agile manifesto says, "Individuals and interactions over processes and tools".

When writing a user story, you should also consider the 3 C's: Card, Conversation, Confirmation. Do both the customer and you understand the meaning of the story?

Does the card meet INVEST criteria? If you answered yes to both those questions then the story is fine.