Working with User Stories: The Missing Parts
Submitted by Karen N. Johnson on Wed, 27/05/2009 - 04:34.
Not long ago, someone emailed me asking me to write about working with user stories. I have a few thoughts about working with user stories. I thought I would write about what I call the “missing parts problem” this time.
In my experiences working with user stories, one element often missing is how a new feature will work with existing features. Notice that I stated “in my experience” because this doesn’t need to be the case. I realize this statement might bring questions to mind – it raised questions in my mind as I tried to explain the missing part problem to a project stakeholder recently. These are the questions and thoughts that roll through my mind and are darn close to a conversation I had recently.
What’s missing in the stories?
The user stories are usually about the new features without hashing out how a new feature will work with existing features. So I end up with 10 user stories about a new feature but the feature is alone. The stories are missing how the new feature will play with other features.
How do I look for the missing parts?
What I do is I create a vision of the new or upgraded feature in my mind; I then walk through the rest of the application with that new feature in mind. Some features will have no – um, perhaps this word works – interplay, no interaction with the new feature. If there’s no interplay to consider, I move on. I do this with aspects of the application that might not be thought of as features – such as active, inactive users, user permissions, etc.
It takes some discipline to walk through that same course over and over but the upside is you get faster at this the more often you use this approach. I’m sweeping through the whole application. I’m not thinking about features in a staccato disconnected fashion.
If you can’t draw that vision in your head, map it out in your notebook. I probably look like I’m zoning out when I gaze out windows or close my eyes but I can see things in my mind pretty clearly. An alternate approach would be to draw a table with a list of the application features and continually run through the list. It’s kind of fun because it’s like holding a puzzle piece and your hand, looking at a jigsaw puzzle and asking yourself, does it (the new feature) fit here? How about here?
I do write a fair amount of grids/tables in my notebooks as I plot out combinations. And if it helps to know, I don’t get my grids right on first drawing – I frequently have to draw them out 2 or 3 times before it’s a grid that works for what I want.
And that thought process is massively helpful because now I’m part of the application, I’m learning. I could be handed the same grid of combinations or permutations of whatever I’ve thought of but I wouldn’t have consumed the knowledge as much as if I drew it out myself. This is the same reason that when I’m given a table I try to force myself to not see the table as complete but instead ask, is anything missing?
Why are there missing parts?
I don’t know. Deep sigh. On one project I worked remotely with a virtual team, the person writing the stories didn’t think I would have input despite my asking to be involved. On another project, the stories were in place when I joined the team. But here’s the more important perspective – I don’t want to whine about not being involved – yeah sure that happens sometimes but more importantly - I would never look to user stories or requirements to think that everything I needed to think about would be written down anyway.
I expect to be the person on the project who thinks of the combinations of things that result in unfortunate results. Or sometimes gets to discover a rock-solid application – whichever the case may be. The combinations of a new feature with an old feature, a new feature under stress, a new feature with challenging data, race conditions, and boundary conditions – the list continues.
If the user stories covered everything, and I all I needed to do was test the user stories, then I wouldn’t be an exploratory tester. I would be a test script executioner or a user story executioner. In either case, I would have disengaged thinking from my work. (Ok, I’ll stop the soapbox.)
How do I continue with testing in this situation?
Happily. I know this is one of the first areas I’m going to think through and see if I can find issues. When I do, I nearly always hear the same reaction from the developers, “Oh.”
But this is probably a good time to point out that I never want to be snotty about finding a defect. Building a good rapport with development is so important. And I make mistakes too – all the time – so it’s best to remember that.
If you have other questions on this subtopic, let me know.
I’ll post about what I do with the parts that are there – the next time.
In my experiences working with user stories, one element often missing is how a new feature will work with existing features. Notice that I stated “in my experience” because this doesn’t need to be the case. I realize this statement might bring questions to mind – it raised questions in my mind as I tried to explain the missing part problem to a project stakeholder recently. These are the questions and thoughts that roll through my mind and are darn close to a conversation I had recently.
What’s missing in the stories?
The user stories are usually about the new features without hashing out how a new feature will work with existing features. So I end up with 10 user stories about a new feature but the feature is alone. The stories are missing how the new feature will play with other features.
How do I look for the missing parts?
What I do is I create a vision of the new or upgraded feature in my mind; I then walk through the rest of the application with that new feature in mind. Some features will have no – um, perhaps this word works – interplay, no interaction with the new feature. If there’s no interplay to consider, I move on. I do this with aspects of the application that might not be thought of as features – such as active, inactive users, user permissions, etc.
It takes some discipline to walk through that same course over and over but the upside is you get faster at this the more often you use this approach. I’m sweeping through the whole application. I’m not thinking about features in a staccato disconnected fashion.
If you can’t draw that vision in your head, map it out in your notebook. I probably look like I’m zoning out when I gaze out windows or close my eyes but I can see things in my mind pretty clearly. An alternate approach would be to draw a table with a list of the application features and continually run through the list. It’s kind of fun because it’s like holding a puzzle piece and your hand, looking at a jigsaw puzzle and asking yourself, does it (the new feature) fit here? How about here?
I do write a fair amount of grids/tables in my notebooks as I plot out combinations. And if it helps to know, I don’t get my grids right on first drawing – I frequently have to draw them out 2 or 3 times before it’s a grid that works for what I want.
And that thought process is massively helpful because now I’m part of the application, I’m learning. I could be handed the same grid of combinations or permutations of whatever I’ve thought of but I wouldn’t have consumed the knowledge as much as if I drew it out myself. This is the same reason that when I’m given a table I try to force myself to not see the table as complete but instead ask, is anything missing?
Why are there missing parts?
I don’t know. Deep sigh. On one project I worked remotely with a virtual team, the person writing the stories didn’t think I would have input despite my asking to be involved. On another project, the stories were in place when I joined the team. But here’s the more important perspective – I don’t want to whine about not being involved – yeah sure that happens sometimes but more importantly - I would never look to user stories or requirements to think that everything I needed to think about would be written down anyway.
I expect to be the person on the project who thinks of the combinations of things that result in unfortunate results. Or sometimes gets to discover a rock-solid application – whichever the case may be. The combinations of a new feature with an old feature, a new feature under stress, a new feature with challenging data, race conditions, and boundary conditions – the list continues.
If the user stories covered everything, and I all I needed to do was test the user stories, then I wouldn’t be an exploratory tester. I would be a test script executioner or a user story executioner. In either case, I would have disengaged thinking from my work. (Ok, I’ll stop the soapbox.)
How do I continue with testing in this situation?
Happily. I know this is one of the first areas I’m going to think through and see if I can find issues. When I do, I nearly always hear the same reaction from the developers, “Oh.”
But this is probably a good time to point out that I never want to be snotty about finding a defect. Building a good rapport with development is so important. And I make mistakes too – all the time – so it’s best to remember that.
If you have other questions on this subtopic, let me know.
I’ll post about what I do with the parts that are there – the next time.