An Abuser Story would not help describe what the user wants, but what the user can't stand about the product.
Something like this:
As Jim I want to stab my eyes out
when I go to update my items
because I can't understand from the current list if they reflect reality
The idea struck me after reflecting on an email I sent to some colleagues who are working on an internal accounting system I use a lot. I expressed to them my hatred of the current state of one part of the product, literally putting "I want to stab my eyes out" in the first sentence of my email.
With an iterative approach we only do what has value and we travel light, but isn't it possible this approach can leave pockets of pain? My question to the world is this: Would characterizing that pain explicitly provide any value over leaping immediately to some user story that would attempt to resolve the pain?
In my case the email I sent actually offered two new features of the system that I thought would solve the problem. They were first to be able to sort data and second to split a single list into three logical lists (current, planned, and future). Then some interesting things happened:
- One of my colleagues suggested I use three containers instead of one container in order to group my items.
- I responded that I would try that, but I still wanted to sort the items.
- The other colleague like my idea of grouping and went to implement it.
Did the context of my abuser story help here? It certainly spurred me to author the note; did it cause my colleagues to behave or respond differently? And does that difference have value enough to bother with writing more Abuser Stories?
I'm not sure, but I think I will start looking at the products I use on a daily basis and collect some of these kinds of stories to get more data.
Oh, and I'm happy to entertain a better name than Abuser Story... but I like how similar Abuser sounds to User :)
No comments:
Post a Comment