Skip navigation.
Home » blogs » Karen N. Johnson's blog

Working with User Stories: The Existing Parts

Submitted by Karen N. Johnson on Sun, 28/06/2009 - 17:20.
Let me digress to make a comparison (in the process I may age myself but so be it) - I think back to the time when desktop publishing was first introduced. With desktop publishing draft copies gained a way of looking complete, finalized and picked up an air of authority based solely on the crisp appearance of the material.

I think of user stories in the same way.

I don’t like to review user stories and believe that they are always “right.” I don’t believe that the stories are always “complete.” And I don’t believe user stories can be the authoritative source for anything more than “what the author thought the application would do at the time they wrote the story.” I am a committed skeptic.

Like reading the answer key while taking a quiz, I don’t like to read user stories before I’ve gathered my own ideas. I worry that the user stories will stifle my testing thoughts.

So what do I really do with user stories? I put them aside at first and …

I think about what functionality is either being introduced or enhanced in the coming build and what test ideas I have collected in my notes already.

I think about existing functionality and what might need to be regression tested.

I review the data model. I expect myself to be able to envision how the application is being changed by reviewing the database changes. I usually can. I pick up more test ideas this way.

Then I pick up the user stories and …

I scan stories for their titles, if the title is written well, I get the point. I don’t continue to read for the details until after I’ve thought about the functionality being introduced or improved. So I’ll take the title of a user story and then think through ways to challenge the premise of the story.

I go back and read the user stories thoroughly. I ask questions. The questions I ask often result in early bug finds and more user stories being written. If I can find issues that early in the process, that’s great.

I write notes while I read the stories. My notes are often more test ideas.

In my experiences with user stories, the most helpful aspect is whenever I learn about a scenario that I didn’t think about – some nuance that I didn’t foresee. I bump these test ideas up early in the process because these are the stories that I feel I can learn from – the stuff I might not have expected.

Despite sounding somewhat negative or skeptical towards user stories, I actually do like them. I generally prefer user stories to more formally written requirements.

User stories are especially more helpful than the requirements that often get written around the medical software I’ve worked with that has so many requirements commanding: “the system shall X” but yet much of the nuance of “how” is not addressed.

I also like to think about and test for the “what if the system doesn’t.” Testing around error conditions and seeing how graceful a system handles certain states or conditions is important. I don’t see user stories written around these concepts though, instead the user stories I’ve worked with have been pretty happy path focused. And I am a rainy day person.

My largest frustration with user stories is if I follow the detailed path that has been drawn out and I find a bug just following the story – a large functional bug. I’m disappointed to realize that unit testing didn’t pick up on the issue. If I think of a variance or nuance from the story, I don’t necessarily expect those issues to have been found or thought about – but I do expect the happy path basic operations to be functional. Just because I expect this and wish for this to be true, doesn’t mean that is what I’ve experienced.

Overall, I think user stories are more digestible than requirements but I can appreciate that some features of an application aren’t described as well in the story format as well as other features. This is why I think having too prescriptive of a story format is a detriment that can be avoided. While, I would not vary the format of each user story because that might result in making the collection of stories hard to follow, I would not use the same format just to be consistent. Some features might be better told in longer prose and some features might be better explained with a grid or a table. I think any format used whether a user story or a requirement stands the chance for not being the best format for the requirement being described. I suppose user stories are like any tool or hammer we learn, there may be a temptation to overuse the format, seeing everything as a nail as the saying goes.

On a recent project where I was working with user stories, I would like to have more involvement earlier on with reviewing and participating in writing the stories. I’m surprised I didn’t/haven’t had that opportunity. I’d like that opportunity – any time I can gain experience from a different perspective (like gaining the experience of producing the stories versus being a consumer of the stories) I learn a great deal.
» Karen N. Johnson's blog | login or register to post comments

would be good to chat

Submitted by Karen N. Johnson on Tue, 30/06/2009 - 22:01.
Antony,

Your hunches about my environment and overall situation are right on. And that factors considerably in the rest of how effective the stories are and many other aspects of the project.

So ... I've worked with stories on a couple of projects but when I write, I often am thinking primarily about "a" situation otherwise it becomes difficult if not tiresome for someone to read ... well in one situation we did X and in another situation we did Y. So I often write based on one situation - choosing either the situation freshest in my memory (this is the case on here). Or I might choose the most effective situation I've worked with and yes, sometimes I choose the worst case scenario I've experienced.

I am longing to work in a situation where I am closer to the developers but this is not the case with the particular project I am referencing. I would like to have a better opportunity to work with the user stories - but which I mean - earlier access to raise questions and help work through ambiguities, etc.

I'm interested in having a followup chat. If we have observations that we can blog back to the community that would be cool.
» login or register to post comments

This comment is a placeholder for a conversation

Submitted by Antony Marcano on Tue, 30/06/2009 - 16:29.

Hi Karen,

Your commentary on how you work with user stories is missing something for me... context - especially when are you doing this... what has happened prior to you engaging in this thought process, when is this process happening and what happens afterwards?

It sounds like you and the project concerned are missing out on valuable opportunities.

From your post it sounds like the project team expect too much of the stories... as if they are "requirements" or specifications. It sounds like you have rejected that notion. Indeed you are correct in doing so. It also sounds like you are working independently of the programmers rather than in close collaboration with them and the customer as the story is discussed prior to implementation.

User stories are a place-holder for a conversation (Cohn)

This is explained well by Ron Jeffries on Card Conversation Confirmation

The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings. This conversation takes place over time, particularly when the story is estimated (usually during release planning), and again at the iteration planning meeting when the story is scheduled for implementation. The conversation is largely verbal, but is often supplemented with documents. You’ll often see spreadsheets showing calculations, sketches of proposed window layouts, even multi-page documents looking much like conventional specifications. Favor discussion when it’ll work, but reflect detail on paper or computerized format.

What the first sentence in that quote should probably say is "...communicated from customer to members of the development team"

I am involved in helping to write the stories with the customer and other team members (programmers, testers, architects, business analysts)... Much like you I also ask questions as we do that, sometimes resulting in stories being split into smaller stories... sometimes generating new stories. Sometimes the 'negative' scenarios (e.g. handling incorrect input) finds its way into another story sometimes it's part of the same story. When it's part of a later story it's usually because the team is going for a little breadth first in order to get early feedback. More often, however, we try to capture the negative scenarios under the banner of the same 'happy-path' story.

The story itself doesn't have that detail on its face. This detail is captured in the form of examples - i.e. the acceptance tests. We (the customer, programmers, testers et-al) exchange examples of what would happen in the context of that story as we try to understand the customer's intent and the agreed examples become the acceptance tests.These are captured at least in summary during planning - sometimes on the back of the story card (although I favour a separate card for each test). These acceptance tests define the scope of the story. Everyone walks away from planning with a good idea of what is expected. This helps to make sure that any post-implementation testing that happens later really needs the application in front of you in order to inspire you to generate those test-ideas that didn't arise beforehand.

During the iteration, we'll flesh each acceptance test out into more detail in turn - just in time for implementation of enough code to get that acceptance test to pass... then we'll move on to the next acceptance test. We repeat that process until all of the acceptance tests for that story are complete. We'll get customer feedback frequently throughout that process - sometimes as often as each acceptance test passing (although more often after several are passing).

As the capabilities of the application increase with each passing acceptance test we'll do exploratory testing to varying degrees... in the first instance on the developers computer then on another environment. We'll use this to identify any tests we hadn't previously thought of. These tests sometimes get added to the current story (if they don't explode the scope of the story out too much). Other times these tests will be aggregated into groups based on affinity between them and these groups each are summarised with a new story. This new story is usually focused on what we want the application to do (rather than what we don't want it to do).

Sometimes such 'misbehaviours' can't be easily summarised as new behaviours (in the form of a story) but I've found that, more often than not, they can be.

Hopefully you can take what I've written here as inspiration for how you might approach the next project that employs user stories... if not, perhaps we could have a conversation so I can better understand the challenges you've faced and share more of my experiences in a way that you can make use of.

Antony Marcano
» login or register to post comments

Comment viewing options

Select your preferred way to display the comments and click 'Save settings' to activate your changes.