17. User Stories
The ticket in the help desk system was short and sweet: “Tech on site: dead mouse.” That seemed like an easy problem to deal with, so when I called the tech – who had gone to the site to replace a drive in the client’s RAID array – I expected to be told what brand mouse and what type of connector I needed to put on order. Instead, my colleague told me he had a real dead mouse: A pesky rodent had gotten into the sealed server enclosure without tripping the containment alarm, then died. Fortunately for him, the mouse corpse had desiccated and was easy to remove and dispose of. Fortunately for me, I was on the phone and didn’t have to deal with it directly.
The above story is a type of user story, but not the kind we’re going to talk about today. It is not without its merits though. We’ll get to that in a few paragraphs. A user story is a short, clear description of a feature told from the perspective of the person or persona that wants the feature. Sounds pretty simple right? It is.
Like many things in Agile, it’s light on the prescription and heavy on the utility. Having said that, there are a few things that we believe are important.
- Story
- Estimate
- Acceptance Criteria
- Discussion
Story
Usually we see these in the format “As a <user/persona> I need
As a developer I need to be able to log people on to a website so that they can be authenticated.
Or
As a service manager I need to prepare documents so that customers understand the services available to them.
Is the developer really the one that needs the feature of being able to log on? More likely it’s a medical student, or professor, or even John Kimball. In the second example, is it the Service Manager that needs the documents or is it more like a user of “X” service? Thinking about who it is that is going to make use of the work you are doing is really important. It may change the way the work gets done. In the first example you may design the logon interface differently if the persona is a medical student than if it is a professor. If it is a logon interface for someone at the service desk it may be different still.
We usually do a pretty good job on the “what they want” section, but additional information about why they want it may also help us make a decision about the way we will solve the problem. If the “why they want it” part is to be compliant with a regulation, it may change the technology the team decides to use.
I like to start all new teams off with this format. Once they get proficient at writing stories with the persona and the “why they want it” parts I will usually let them decide if they want to change up the format to better suit the team. Some teams change it, some stay with it.
Estimate
This is an area of a lot of controversy. Some people think estimates are good, some not so much. Some people believe all stories should be the same size. I’ve done estimates with story points and I’ve done them where every story gets the same value. Each have offered some level of success. The usefulness for me lies in a side effect that comes from a team estimating together. The discussion. If you are estimating a story with your team and one person has a high estimate and one person has a low estimate, I get excited. I love it when that happens. In almost every case a spirited discussion ensues where both sides explain why they think the story is big or why they think it is small. Most often you hear great stories of how they have done something similar in the past. How it either took longer and had all kinds of complexity or about how there was a simpler way of getting the work done. The key is to have that talk and decide as a team.
Acceptance Criteria
Perhaps the most important part of the story. The steering wheel for the car. The wife to the husband. The Steve Jobs for Apple. It’s the part of the story that helps us confirm that it is done. It’s the part that explains what we will show the customer. In our first example our acceptance criteria might be “Medical student can go to http://blahblahblah, enter their user name into the user name field, enter their password in the password field, press submit and they get forwarded to the application.” You could imagine how this could be demonstrated.
You will often hear people say “what is your definition of done for that story?” How will you know when it is complete? When you can demonstrate what is in the acceptance criteria, the story is done. Some teams may decide that stories have to be in production before they can be considered done. Some teams may be ok with just demonstrating that the acceptance criteria has been satisfied. Either way, the team should have a clear, consistent approach to what done means for their stories.
One thing I hear all the time is that the story is done except I have to clean up this or that. In fact, I’m not the only one that has heard this over and over again. It has been said so frequently that the notion of “done done” has come to mean really done or completely done. Seems silly. Almost could be a gag in a Monty Python skit.
Guy dressed as a woman 1: My parrot is done
Guy dressed as a woman 2: No it’s not.
Guy dressed as a woman 1: Yes it is…it’s done done.
Guy dressed as a woman 2: Done done? Yeah, done done.
Guy dressed as a woman 1: You have one done parrot.
The basic idea here is that Done Done means completely done. No extra little loose ends to tie up. That thing is DONE!
Discussion
Sometimes you’ll hear people talk about User Stories as artifacts for discussions. In other words, it’s the beginning of a contract that the writer has with the team and the Product Owner to say, we will talk about this. Just like in the estimation, the power is in the discussion. Now if we go back to the mouse story we began this tome with, you can see where a discussion up front would have helped. If there was a story that talked about a dead mouse, the first question I might ask is, “do I need rubber gloves, a dustpan and a broom or should I bring a spare logitech pointing device?”
0 comments :
Post a Comment