Writing Agnostic Agile Stories
Not a religious post, although Agile might be a religion for some.
How it usually works
Love it or hate it, Agile and its methodology has taken over much of the tech business world. I’ve personally been in situations where it’s really helped keep things on track and realistic and in others where it’s caused needless overhead and micromanagement. As they say, YMMV (Your Mileage May Vary).
In short, an Agile story defines a feature of a larger effort in such a way as it can generally be picked up by a developer and finished in 2 weeks (aka a Sprint) or less. It really should generally be a few days or more. Teams might have 5–20 stories to complete a sprint depending on complexity, timing and budget.
For example, a dating app might have a story allowing a person to pick a custom avatar or send a quick virtual “gift” to someone else. However, if that effort starts to look like it might take more than a defined sprint (some can be as short as 1 week), then you’ll probably want to figure out a way of splitting the story into more defined pieces and/or turning into what is called an Epic if they’re more than three stories. Epics aren’t usually as cool as they sound btw.
A typical story might start off in what’s called the Backlog which might be a hodgepodge of ideas or it might be well understood and prioritized. It might be one of many new stories as part of a completely new project with a lot of unknowns or it may be just a single one getting added to a pre-existing project where the context is pretty much nailed down. The initial idea might only consist of a single line like “Add a Custom Avatar”.
It’s a good idea to be able to write a Story
Even though I’m a UX Designer, I’ve sometimes had to be in the position of needing to write stories for development teams where there might not be a product owner available or due to my interactions with all the primary stakeholders (and the creator of the designs themselves) I was in the best position to write them. So it’s a good idea to understand the basic principles even if you’re not a Product Owner. UX only Stories do have a tendency to be larger and “looser” since by definition, the specifics haven’t been nailed down as much as when they reach the development stage.
The Basics
Stories usually are phrased in this format:
“As a <role>, I want to <do something> so that I can <get some value/result>”.
This covers the Who, What and Why. The Who generally comes from some Persona or role, the Want is what they’re expecting to do because of the value or result they need, the Why. The usual format doesn’t cover the Where, When and How.
Let’s take Add a Custom Avatar and phrase it in an Agile Story format:
If I were handed the title from the backlog, I might express it this way.
“As a dater, I want to add and display a custom avatar so that I can visually differentiate myself from others on the app.”
A little extra
My personal take on the format expands on it adding a When or Where because this gives the context in which the situation occurs. I lean towards the point of view that Personas, although useful, are sometimes not as necessary as designing for the situation a person finds themselves and might even be unnecessary. I have a tendency to take more of a Jobs To Be Done approach. That isn’t to say that the “as of” part can’t be useful even in that case. A site or app admin usually has much different needs and would react differently than a standard user. So saying As an Admin vs as a Dater, might be pretty critical.
Adding a when/where fits in with the JTBD because it’s a situation where anyone might find themselves.
Let’s add the When:
“As a dater, when others are viewing my Profile, comments or other public facing content, I want to be able to customize my avatar so that I am differentiated from others.”
The other part of a Story is the “Acceptance Criteria”. That sounds so underwhelming doesn’t it? People just need to… accept it. Maybe we should call it the Awesome Criteria instead? Oh well, it is what it is.
This is generally a list of what must be in this feature in order to design, develop or test against it. And for whoever is asking for it to…Accept it. “Yes, that is…Acceptable! No, I changed my mind, that is not…Acceptable!” You get the idea…
Once again, if the list starts to get too long, let’s say beyond seven bullet points, you might want to consider losing some criteria or breaking it up into other stories. It might be trying to do too much all on its lonesome.
Don’t get too specific
You want to be as generic as possible and don’t box the designer or developer in too much. Specifics can always be added and really might belong in “tasks” or subtasks associated with the story. The goal is to keep things focused on the value of what needs to be done and not on the exact implementation (which might vary or need to change when you get in the weeds).
Here’s an example of some criteria from Customize My Avatar.
Let’s try something “real”
We’re assuming they’ve been assigned a default Avatar. This may or may not encompass uploading an Avatar. Maybe it only lets them select some Graphic based choices. These are some of the discussions you’ll probably want to have with the other stakeholders (I always have an image of people holding wooden stakes over a vampire’s chest when this term is used) before really implementing a story.
Let’s outline some standard stuff people usually expect for avatars. User Research might say otherwise though.
The example
Disclaimer: I’m not a professional Product Owner so take my examples with a grain of salt.
Acceptance Criteria:
- They can view their current avatar
- An action presents them with ability to update it
- They can add a picture for their avatar
- They may adjust the picture (e.g. crop, resize, move)
- They can preview it
- They can select from a range of pre-made avatars
- They have the ability to exit from the process or apply it.
- They can revert to any previous avatars
- They can re-adjust the current avatar
For a UX story, this might be a bit of a decent lift but doable. I’d still want to break up the effort a bit though. I’m positive devs would look at this and say it’s an Epic for them, with probably each bullet needing its own story or at least many of them grouped into their own stories like Select from a range of avatars, Adjustments and Re-adjust and Selection/Reversion.
As a side note, I usually prefer to use the Kanban approach for UX stories over the Sprint Board approach. It’s more flexible and implies more back and forth between review and iteration. Then, when everything has been worked out by the business, design and dev leads, those stories can be moved into the dev sprint board for “grooming/evaluation” and either expanded upon with technical details or broken up into more manageable pieces. However, to each their own…
In practice, adjustment would definitely be its own story as well as selection of pre-made avatars. Although the pre-mades might wind up being the first effort criteria and the uploading a second effort. Reversion to previous avatars would be a Want To or Could Have but would probably die or wither on the vine in the backlog unless some stakeholder or user feedback makes it a priority somehow. Readjustment would be a Should have.
Why am I using these terms? It’s called the MoSCoW mnemonic. Must have, Should Have, Could Have, Want to have. Usually only the first two actually ever get done but it’s good to track other ideas as well.
What you’ll finally get
So this is probably what would survive given my experience.
- An action presents them with ability to update it
- They can add a picture for their avatar
- They may adjust the picture (e.g. crop, resize, move)
- They can preview it
- They have the ability to exit from the process or apply it.
Notice how I’m not getting technical or making design decisions at this stage?
Too much information!
Here’s the other way you sometimes see. It has too many proscriptive details that may or may not be a good idea or even feasible yet:
- A button in the Profile next to the Avatar triggers a pop up of an 800 x 600 modal that displays their current avatar.
- They can upload a picture for their avatar. It should only allow jpegs or pngs and needs to be a minimum of 400 x 400 and a maximum of 1280 x 1280. The ratio needs to be equal. Anything else generates an error that says, “You’re bad. Very bad!” The picture needs to be uploaded in 500ms using Cloudinary via a serverless function
- They may adjust the picture (e.g. crop, resize, move). A small hand will appear when they move it and a bar when they crop it. The preview will be 400 x 400 and the background is #333.
- By clicking on the image they can see the final result
- They can click a button that says Cancel to exit or an “x” icon in the corner
- Clicking a Save button applies the change.
Why would this be a problem?
For one thing, the actions may or may not be triggered by buttons. Maybe this is something that occurs when you select the image or choose something from a dropdown. We haven’t explored options and these details might be better off being linked to from the designs where annotations give in context guidance. Perhaps they’re already addressed in the organization design system or conventions.
The real danger is that once a story has been accepted into a sprint, it should not theoretically be changed. So, if the devs and designers run into problems or find a better method a lot of renegotiating needs to be done and now can be more difficult to get it marked as done and accepted when reviewed. If things were kept more generic from the start these problems might not occur. One could say that’s more of a problem with the Agile process itself than the story writing but it nonetheless causes an issue if that’s the process you’ve chosen.
If things were kept more generic from the start these problems might not occur.
Being that specific might cause problems in other stories as well that rely on the specifics of that story.
You might still need to be a little specific
With that said, for projects that have codified certain design or development conventions, it might be justified being specific. Maybe Cloudinary is being used to upload files elsewhere and perhaps it has some very constrained design or development options based on licensing. (Cloudinary is actually very good, this is just an example. I’m not affiliated with them in any way, btw.). This won’t change so it might be best to be explicit in that case.
Try it out!
Writing a good story takes practice and varies according to the situation. I’m not going to claim I’m the best at it, but I’ve found myself forming a story as a thinking tool to get my head around a new feature even if not operating in a formal Agile context. If you haven’t given it a try, I recommend doing so. If you’re an old hand, maybe this has given you some food for thought. Happy story writing!
