I have been making use of the concept of user stories on my current project. Although we have a functional specification document, we are still asking our users to write user stories for each module in our specification. I have found the user story to be a great tool for helping my team understand what it is that the user is trying to accomplish. The functional specification has some great detail, but the user story seems to always flush out small details prior to development that had we relied on the specification alone, we would have missed until testing.
The user stories we request from our client includes a short description of the functionality, a notes area for key points, and a list of client acceptance tests. This list of tests should be, from the user perspective, what the user expects to see happen before they consider each module to be complete. The exercise of asking the users to come up with a list of tests on their own has also helped us to identify change before we start development. This list of tests gives my team a quantifiable set of user expectations up front that helps us build our solution to meet their needs, rather than setting the user expectations to meet our solution.
When we first introduced user stories to our clients, we walked through the creation of a couple together. This helped our users get an idea of what might be included in the user story. Arguably, by doing the walk-through, we could have inadvertently shaded our user’s perspective. I still feel that the walk-through was a good way to get the users comfortable with what it is we wanted from them.
One snagging point that keeps bothering me about the user story in our project, is that we are not getting input from the end users. Our user stories are written by a business analyst who works for the client and the client project sponsor. While I much prefer a higher-level user to no user, I feel that the spirit of the user story is that the end-user is the one writing the story.
I have also heard of developers writing user stories when users are unwilling or unable to write the stories on their own. Again, I am sure that a developer-written story is better than no story. But is that really a user story? Or is this just another kind of documentation? I wonder if we aren’t missing the point of a user story when someone other than the end user is writing it.
Subscribe to:
Post Comments (Atom)
5 comments:
If a business analyst is writing the stories, the obvious problem is that you can't tell if the business analyst is giving you the correct story. If the users aren't willing to write the stories, how do you know that they're willing to meet with the business analyst?
If I was asked to write a story as a developer, I would refuse (in a tactful way) and bring the issue up to the project manager or whoever is leading the project.
If user stores are going to be used, then they should be used correctly. If not, then whoever is leading the project probably isn't buying into the concept of user stories - otherwise the users would be cooporative. If 100% of the project team won't buy into it, then I'd assume that you won't reap any of the benefits that user stories provide - either because they won't be used correctly or they won't be used at all.
If an analyst or developer writes the stories, its ultimately the end user who suffers in the end because they will receive a product built to somebody else's specifications (because somebody else is writing the tests).
In your situation, I'd bring up the issue to the project leader or project manager. If you can't get buy-in from them, then I'd explain to them that the end-users will suffer and project quality will fall. If you still don't get buy-in, then.... make lemonade out of lemons? :)
Mike-
That is EXACTLY my concern, as well. I am acting as the project lead and am in charge of managing the client relationship. The problem we have run into is getting our client sponsor to understand that it is not good enough for them to provide us with their analyst's time. We need their end users. The client sponsor is reluctant to ask his end users to be part of the project team because they are employees paid only on commission. Commission only employees would much rather spend thier time out following leads than working with our tool. Thus far, we have made lemonade. I do continue to push for at least one end user to be involved because you are right; if we do not have the END user's story, then we are writing what the analyst feels the end user needs rahter than what the end user feels they need.
--Valerie
Any news or developments on this issue?
Mike-
I was able to sit down with my end user in a meeting to discuss requirements, rather than sitting down with only the analyst. This is a first on this project, and I appreciated the opportunity. We uncovered a lot of detail in the meeting, and at the end of the meeting, I gave the user and my analyst the to-do of writing the user story together. My user was happy to help.
My analyst, however, did not include the user in her writing of the user story.
I think that my solution to the missing end user is only going to be solved if I sit together with the end user and analyst to write the user stories together.
Do you have any similar experiences?
Thanks-
Valerie
This is a really interesting dialog.
There is a whole sub-industry related to user experience design and traditional product design. One of their cornerstones is observing the user and creating the specs from those observations. Check out cooper.com, uie.com, ok-cancel.com, ixdg.org, ideo.com (product design), and many more. I started building a tool so that you could use video, audio, and screen to record user design sessions, focus groups or whatever and communicate those design sessions back to all team members the actual user experience/story (www.usersfirst.com). It has a bent towards software usability, but I so want it to be used more in the design phase, with participatory design, focus groups, contextual inquiry, ethnographic research, blah blah blah. --smile-- But, I have to get the product completed first.
Valerie, I think your thought about sitting with the user and analyst is a great idea. Adapt the story medium to however the user wants to communicate it, draw pictures, write it out, whatever. As you have said, it is so important that their needs/goals are communicated, and are leading the product design and ultimately the development.
Best regards,
Pete Gordon
usersfirst.com
Post a Comment